案例一：条件字段函数操作
交易记录表 tradelog ：交易流水号（tradeid）、交易员 id（operator）、交易时间（t_modified）
2016 初到 2018 年底的所有数据，统计所有年份中 7 月交易总数。t_modified 上有索引，但特别久才返回：字段函数计算，用不上索引了。
mysql> select count(*) from tradelog where month(t_modified)=7;
为什么wheret_modified='2018-7-1’可用索引(绿色箭头，快速定位)，month(t_modified)=7不行？
B+ 树提供的这个快速定位能力，同一层兄弟节点的有序性。month() 7 ，第一层不知怎么办。
索引做函数，破坏有序性，优化器放弃树搜索（不是放弃用这个索引）。
优化器遍历主键索引/索引 t_modified， t_modified 更小，比主键索引快。
key="t_modified"用 t_modified 索引；插入 10 万行数据，rows=100335扫描所有值；Extra Using index用覆盖索引。
month() 函数导致全索引扫描。为用上索引定位能力，范围查询：
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');
上线时间更早，其他年份补齐。
优化器“偷懒”，select * from tradelog where id + 1 = 10000 +1 不改变有序性，不能用 id 索引快速定位到 9999。改10000-1 可以。
案例二：隐式类型转换
mysql> select * from tradelog where tradeid=110717; tradeid 有索引，explain走全表扫描。 varchar(32)，参数整型，需类型转换。
数据类型转换规则更多，记不住，简单方法 :select “10”> 9 的结果：
1. (MYSQL规则)是“将字符串转成数字”，做数字比较， 1；
2. 规则是“将数字转成字符串”，字符串比较， 0。
索引函数操作，放弃树搜索,相当于：mysql> select * from tradelog where CAST(tradid AS signed int) = 110717;
id 是int ，是否全表扫描？select * from tradelog where id="83126";
答：id 类型是整数，参数字符串，可用索引。
案例三：隐式字符编码转换
trade_detail，操作细节
查询 id=2所有操作步骤信息，mysql> select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2;
1. tradelog 查 id=2 ，主键索引rows=1 只扫描一行；
2. key=NULL，没有用上交易详情表 trade_detail tradeid 索引，全表扫描。
不符合预期。没用索引，字符集不同， utf8， utf8mb4，
从 tradelog 表中取 tradeid 字段，trade_detail查询匹配字段。tradelog 驱动表，trade_detail 被驱动表
mysql> select * from trade_detail where tradeid=$L2.tradeid.value;
utf8mb4 是 utf8 超集。避免截断数据错误，“按数据长度增加方向”转换。
换成 utf8mb4，再跟 L2 做比较：select * from trade_detail where CONVERT(traideid USING utf8mb4)=$L2.tradeid.value;
CONVERT() 函数，输入字符串转成 utf8mb4 字符集。被驱动表加函数操作
mysql>select l.operator from tradelog l , trade_detail d where d.tradeid=l.tradeid and d.id=4;trade_detail成驱动表， tradelog 里索引 (tradeid)，扫描行数是 1。
这次用上被驱动表 tradeid 索引：
驱动表 trade_detail里 id=4 的行记为 R4，连接时候（图 5 的第 3 步），被驱动表 tradelog：select operator from tradelog where traideid =$R4.tradeid.value（字符集是 utf8转成 utf8mb4）改写成：
加在输入参数上：select operator from tradelog where traideid =CONVERT($R4.tradeid.value USING utf8mb4);
优化语句：select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2;
（1）trade_detail 的 tradeid 改成 utf8mb4，没有转换问题
alter table trade_detail modify tradeid varchar(32) CHARACTER SET utf8mb4 default null;
（2）修改 SQL （数据量比较大）
mysql> select d.* from tradelog l , trade_detail d where d.tradeid=CONVERT(l.tradeid USING utf8) and l.id=2;
主动把 l.tradeid 转 utf8，避免被驱动表转换，索引走对。
小结
三个例子，说同一件事：索引做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。
例子2：隐式类型转换
例子3：隐式字符编码转换，都跟例子1一样，索引上做函数操作，导致全索引扫描。
优化器“偷懒”，where id+1=1000 改成 id=1000-1 用索引快速查找，不主动重写。
思考题
类似性能问题原因是什么，怎么解决？
mysql> CREATE TABLE `table_a` (
`id` int(11) NOT NULL,
`b` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `b` (`b`)
) ENGINE=InnoDB;
100 万行数据，10 万行数据b =’1234567890’ mysql> select * from table_a where b='1234567890abcd';
（1）最理想 b 定义的是 varchar(10)，返回空
（2）’1234567890abcd’拿到索引做匹配，没快速判断出索引树 b 没值，返回空。
（3）MySQL 不这么做。执行很慢：
1. 传引擎执行时，做字符截断。引擎定义长度10，截前 10 ’1234567890’匹配；
2. 满足有 10 万行；
3. select *，10 万次回表；
4. 查整行到 server 层判断，b 值都不是’1234567890abcd’;
5. 返回结果是空。
经过函数，拿到结果，server 层做一轮判断。
评论1
隐式类型转换坑。任务表记录待执行任务：
CREATE TABLE `task` (
`task_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
`task_type` int(11) DEFAULT NULL COMMENT '任务类型id',
`task_rfid` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '关联外键1',
PRIMARY KEY (`task_id`)
) ENGINE=InnoDB AUTO_INCREMENT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='任务表';
select * from task where task_rfid =123;//业务主键，数字
有隐式转换问题，只有几千条记录，没有什么感觉。对应的历史表，几千万 select * from task_history where task_rfid =99;
超时报错,task_rfid 没有索引，task_rfid =‘99’全表扫描。
根据creat_time字段猜task_id的范围，估出id范围。select * from task_history where task_rfid =99 and id between ？ and ？
评论2
多表连接时，mysql怎么选择驱动表和被驱动表的？
相同模板语句，匹配行数不同，执行时间相差大。 order by 更明显。
