这些个索引坑，你们是否有踩过呢？ _索引

做业务开发的同学都知道，有些SQL看起来没啥问题，索引也用到了，但就是很慢.......
今天我们来通过几个常见的例子来深入探究下SQL慢的原因
案例一假设你现在维护了一个帖子表，包含帖子id（tweet_id）、用户id（user_id）、时间（gmt_create）等字段。为了便于描述，我们先忽略其他字段。这个表的建表语句如下：
MySQL> CREATE TABLE `t_tweet` ( `id` int(11) NOT NULL, `tweet_id` varchar(32) DEFAULT NULL, `user_id` int(11) DEFAULT NULL, `gmt_create` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `tweet_id` (`tweet_id`), KEY `gmt_create` (`gmt_create`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;复制代码假设，现在已经记录了从2016年初到2018年底的所有数据，有一个需求是，要统计发生在所有年份中7月份的帖子记录总数。这个逻辑看上去并不复杂，你的SQL语句可能会这么写：
select count(*) from t_tweet where month(gmt_create)=7;复制代码由于gmt_create字段上有索引，于是你就很放心地在生产库中执行了这条语句，但却发现执行了特别久，才返回了结果。
如果你问DBA同事为什么会出现这样的情况，他大概会告诉你：如果对字段做了函数计算，就用不上索引了，这是MySQL的规定。
如果你已经学过了InnoDB的索引结构了，可以再追问一句，为什么？
为什么条件是where gmt_create='2018-7-1’的时候可以用上索引，而改成where month(gmt_create)=7的时候就不行了？
下面是这个gmt_create索引的示意图。方框上面的数字就是month()函数对应的值。

文章插图

如果你的SQL语句条件用的是where gmt_create='2018-7-1’的话，引擎就会按照上面绿色箭头的路线，快速定位到 gmt_create='2018-7-1’需要的结果。
实际上，B+树提供的这个快速定位能力，来源于同一层兄弟节点的有序性。
【这些个索引坑，你们是否有踩过呢？】但是，如果计算month()函数的话，你会看到传入7的时候，在树的第一层就不知道该怎么办了。也就是说，对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。
需要注意的是，优化器并不是要放弃使用这个索引。
在这个例子里，放弃了树搜索功能，优化器可以选择遍历主键索引，也可以选择遍历索引 gmt_create，优化器对比索引大小后发现，索引gmt_create更小，遍历这个索引比遍历主键索引来得更快。因此最终还是会选择索引gmt_create 。可以使用explain命令，查看一下这条SQL语句的执行结果
key="gmt_create"表示的是，使用了gmt_create这个索引；我在测试表数据中插入了10万行数据，rows=100335，说明这条语句扫描了整个索引的所有值；Extra字段的Using index，表示的是使用了覆盖索引。
也就是说，由于在gmt_create字段加了month()函数操作，导致了全索引扫描。
到这里我给你说明了，由于加了month()函数操作，MySQL无法再使用索引快速定位功能，而只能使用全索引扫描。
优化器在某些问题上确实有“偷懒”行为，即使是对于不改变有序性的函数，也不会考虑使用索引。
比如，对于select * from t_tweet where id + 1 = 10000这个SQL语句，这个加1操作并不会改变有序性，但是MySQL优化器还是不能用id索引快速定位到9999这一行。所以，需要你在写 SQL语句的时候，手动改写成 where id = 10000 -1才可以。
案例二我们一起看一下这条SQL语句：
select * from t_tweet where tweet_id=110717;复制代码交易编号tweet_id这个字段上，本来就有索引，但是explain的结果却显示，这条语句需要走全表扫描。你可能也发现了，tweet_id的字段类型是varchar(32)，而输入的参数却是整型，所以需要做类型转换。
那么，现在这里就有两个问题：