18 | 为什么这些SQL语句逻辑相同，性能却差异巨大？

MySQL45讲

实践篇

18 | 为什么这些SQL语句逻辑相同，性能却差异巨大？

案例一：条件字段函数操作

CREATE TABLE `tradelog` (
  `id` int(11) NOT NULL,
  `tradeid` varchar(32) DEFAULT NULL,
  `operator` int(11) DEFAULT NULL,
  `t_modified` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `tradeid` (`tradeid`),
  KEY `t_modified` (`t_modified`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

select count(*) from tradelog where month(t_modified)=7;

对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。
需要注意的是，优化器并不是要放弃使用这个索引。
使用 explain 命令查看语句的执行结果：

在测试表数据中插入了 10 万行数据，rows=100335，说明这条语句扫描了整个索引的所有值；Extra 字段的 Using index，表示的是使用了覆盖索引。
由于在 t_modified 字段加了 month() 函数操作，导致了全索引扫描。

案例二：隐式类型转换

select * from tradelog where tradeid=110717;

交易编号 tradeid 是索引字段，但是 explain 的结果却显示这条语句需要走全表扫描。

数据类型转换的规则是什么？
和什么类型比较就转换成什么类型

为什么有数据类型转换，就需要走全索引扫描？
对于优化器来说，这个语句相当于：

select * from tradelog where  CAST(tradid AS signed int) = 110717;

触发了对索引字段做函数操作，优化器会放弃走树搜索功能的的规则。

案例三：隐式字符编码转换

CREATE TABLE `trade_detail` (
  `id` int(11) NOT NULL,
  `tradeid` varchar(32) DEFAULT NULL,
  `trade_step` int(11) DEFAULT NULL, /*操作步骤*/
  `step_info` varchar(32) DEFAULT NULL, /*步骤信息*/
  PRIMARY KEY (`id`),
  KEY `tradeid` (`tradeid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into tradelog values(1, 'aaaaaaaa', 1000, now());
insert into tradelog values(2, 'aaaaaaab', 1000, now());
insert into tradelog values(3, 'aaaaaaac', 1000, now());

insert into trade_detail values(1, 'aaaaaaaa', 1, 'add');
insert into trade_detail values(2, 'aaaaaaaa', 2, 'update');
insert into trade_detail values(3, 'aaaaaaaa', 3, 'commit');
insert into trade_detail values(4, 'aaaaaaab', 1, 'add');
insert into trade_detail values(5, 'aaaaaaab', 2, 'update');
insert into trade_detail values(6, 'aaaaaaab', 3, 'update again');
insert into trade_detail values(7, 'aaaaaaab', 4, 'commit');
insert into trade_detail values(8, 'aaaaaaac', 1, 'add');
insert into trade_detail values(9, 'aaaaaaac', 2, 'update');
insert into trade_detail values(10, 'aaaaaaac', 3, 'update again');
insert into trade_detail values(11, 'aaaaaaac', 4, 'commit');

select d.* from tradelog l, trade_detail d where d.tradeid=l.tradeid and l.id=2; /*语句Q1*/

语句 Q1 的执行过程：

第二行 key=NULL，表示没有用上交易详情表 trade_detail 上的 tradeid 索引，进行了全表扫描。
两个表的字符集不同，做表连接查询的时候用不上关联字段的索引。

当这两个类型的字符串在做比较的时候，MySQL 会先统一字符集，然后再做比较。

utf8mb4 是 utf8 的超集。类似地，在程序设计语言里面，做自动类型转换的时候，为了避免数据在转换过程中由于截断导致数据错误，都是“按数据长度增加的方向”进行转换的。

对优化器来说，以上语句相当于：

select * from trade_detail  where CONVERT(traideid USING utf8mb4)=$L2.tradeid.value; 

触发了原则：对索引字段做函数操作，优化器会放弃走树搜索功能。

连接过程中在被驱动表的索引字段上加函数操作，会导致对被驱动表做全表扫描。

相关示例：

select l.operator from tradelog l , trade_detail d where d.tradeid=l.tradeid and d.id=4;

查询操作用上了被驱动表 tradelog 里的索引 (tradeid)。

为什么这次能用上被驱动表的 tradeid 索引？
被驱动表 tradelog 上执行的就是类似这样的 SQL 语句：

select operator from tradelog  where traideid =CONVERT($R4.tradeid.value USING utf8mb4); 

CONVERT 函数是加在输入参数上的，这样可以用上被驱动表的 traideid 索引。

优化语句的执行过程，有两种做法：

1. 修改字符集（优先）

alter table trade_detail modify tradeid varchar(32) CHARACTER SET utf8mb4 default null;

2. 如果数据量比较大， 或者业务上暂时不能做 DDL，则采用修改 SQL 语句的方法

select d.* from tradelog l , trade_detail d where d.tradeid=CONVERT(l.tradeid USING utf8) and l.id=2; 

连接过程中在驱动表的索引字段上加函数操作，不会做全表扫描。