在 MySQL 中，有很多看上去逻辑相同，但性能却差异巨大的 SQL 语句。对这些语句使用不当的话，就会不经意间导致整个数据库的压力变大。
案例一：条件字段函数操作
假设有如下语句，并且字段 t_modified 上有索引：
mysql> select count(*) from tradelog where month(t_modified)=7;
那么这条语句会很快地返回数据吗？
答案是否定的。
对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就会放弃走树索引。
这里，由于加了 month() 函数操作，MySQL 无法再使用索引快速定位功能，而只能使用全索引扫描。
语句优化：
mysql> select count(*) from tradelog where
-> (t_modified >= '2016-7-1' and t_modified<'2016-8-1') or
-> (t_modified >= '2017-7-1' and t_modified<'2017-8-1') or
-> (t_modified >= '2018-7-1' and t_modified<'2018-8-1');
案例二：隐式类型转换
有如下语句：
mysql> select * from tradelog where tradeid=110717;
tradeid 字段是 varchar(32) 类型的，而对比的参数是整数，所有就需要做类型转换。
1、数据类型转换的规则是什么？
看 select "10" > 9 的结果：
① 如果结果是 1，那么就是将字符串转换成数字；
② 如果结果是 0，那么就是将数字转换成字符串；
如果是将字符串转换成数字，那么上面的语句对应的就是：
mysql> select * from tradelog where CAST(tradid AS signed int) = 110717;
其实就出发了案例一里面的规则，对字符串索引进行了函数操作，优化器就会放弃树搜索的功能，进行全表搜索。
案例三：隐式字符编码转换
如下语句：
mysql> select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2; /* 语句 Q1*/
如果表 tradelog(utf8) 和表 trade_detail(utf8mb4) 的字符集不同，那么 d.tradeid=l.tradeid 条件也会导致全表扫描。
字符集 utf8mb4 是 utf8 的超集，所以当这两个类型的字符串在做比较的时候，MySQL 内部的操作是，先把 utf8 字符串转成 utf8mb4 字符集，再做比较。
同样，触发了案例一中的条件。
你的关注是对我最大的鼓励！
关注本公众号，后台回复「2018」即可获取传智播客 2018 最新 Python 和 Java 教程。
公众号提供CSDN资源免费下载服务！
