每周坚持更新两篇博客的计划就在上周又中断了，说好的坚持下去呢？不说太多废话了，从现在开始每周坚持两篇博客，欢迎大家积极监督！本篇文章是自己新专栏（sql优化）的第一篇文章，希望对大家有所帮助！
相信大家平常在使用数据库开发过程中都离不开索引，因为索引帮助我们大大提高了查询数据的效率，在一定程度上提高了整体系统的性能。但是如果我们使用不当的话就会引起索引失效从而导致查询时走了全表扫描，一旦走了全表扫描，数据量如果是千万级别甚至是亿万级别的话将会导致查询非常缓慢！所以无论如何我们一定要注意防范数据库索引失效！本篇文章讲述了导致数据库索引失效的一种情况，其它情况大家可以自行搜索。好，下面开始步入正题。
之前有个常规版本晚上部署到生产后突然系统连续弹出了很多关于慢sql的告警，仔细一看，还都是同一个sql语句，该sql语句如下所示:
select * from t_online_trade where order_no = 815504020005108333 and pay_status = 'SUCCESS'
当时我就纳闷了，一个好好的sql怎么会查询这么慢呢？经过一番分析，我发现order_id在数据库中是varchar类型，但是我居然给它传了整型，这会不会就是传说中字段类型的隐式转换而导致的索引失效呢？为了验证我的设想，我于是找到了这个sql所对应的mybatis相关代码，如下所示：
从如上截图中不难看出，order_no在数据库中数据类型（jdbcType）为varchar字符串类型的，但在传参时却传了个长整型Long，这恰好验证了我刚刚的设想，于是不管三七二十一，我将Long类型修改成String类型，如下所示：
当修改完重新部署到生产后发现已经没有慢sql的相关报警了，慢sql优化成功！
1.思考一： 隐式转换是如何使索引失效的？
其实这个问题非常好解答。你只需要使用explain来分析该sql的执行计划就可知道答案了，我贴出了如下的截图，大家可以看看。
通过以上两张截图可以知道如果order_id字段传了整型的值的话就会导致无法使用idx_order_id索引从而走了全表扫描！相反如果传了与之对应的字符串类型则可以走idx_order_id这个索引，这将大大地提高查询效率。
2.思考二： 后面看了阿里巴巴java开发手册中关于索引规约的内容，里面就提及到了这一点：
- 【推荐】防止因字段类型不同造成的隐式转换，导致索引失效。
3.思考三： 为什么#{orderNo,jdbcType=VARCHAR}中的jdbcType=VARCHAR不能帮我们进行Long到varchar的转换呢?
这个问题是我后面翻阅了Mybatis的相关文档才解决的，文档找中大体上说到：jdbcType是jdbc的要求而非Mybatis的要求，所以也就是说jdbcType只会在直接面向JDBC编程时才会生效，否则不生效。我把答案截图贴出来，大家可以自行理解和体会下：
