10讲MySQL为什么有时候会选错索引

1 使用存储过程生成假数据

delimiter ;;
create procedure idata()
begin
  declare i int;
  set i=1;
  while(i<=100000)do
    insert into t values(i, i, i);
    set i=i+1;
  end while;
end;;
delimiter ;
call idata();

2 会走索引 select * from t where a between 10000 and 20000;
3 一个 mysql 选错索引的案例

image.png

4 slow log 可以查看具体执行情况
5 force index(a)可以强制使用索引
6 set long_query_time=0; 所有语句都会被记录到 slow log
7 slow log 结果

image.png

8 如何查看 slow log
9 对应的是平常 “不断删除历史数据和新增数据”的场景 , 此时会选错索引
10 优化器的目的 , 最小的代价执行语句 , 最小代价 : 扫描行数少 , 则 IO 少,CPU 消耗少
11 优化器其他判断准则 , 是否使用临时表 , 是否需要排序
12 执行语句之前优化器并不能精确判断扫描行数
13 通过使用”区分度”进行预估
14 区分度就是索引上的cardinality(基数) , 越大区分度越好
15 cardinality是通过采样统计取值的 , 并不精确
16 采样统计的方法 : 取n个数据页 , 取不同值数的平均值 , 乘以数据页数量
17 当变更的数据超过1/M的时候会重新采样统计
18 采样统计可存在磁盘中或只存在内存中
19 通过innodb_stats_persistent修改 , on 是持久化,N是20，M是10 , off 是内存中,N是8，M是16
20 采样统计的值还是很容易不准的 , 但大体上依然是差不多的
21 上面那个案例的两个语句的预估行数

image.png

image.png

22 Q1 语句的预估行数是接近的 , 但是 Q2 的预估行数是错误的
23 此时由于优化器还需要考虑回表去扫描的代价 , 并且认为直接扫描主键索引更快 , 因此当不 force index 的时候会用全表扫描 , 但显然从执行时间来看不是最快的

23 但是主要的问题还是错误的预估行数造成的 , 图 1 就没问题啊
24 analyze table t , 重建 统计

image.png

25 另一个案例 , 说明优化器不只通过预估行数来分析
26 select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;
27 几种解决方案 , 1 修改语义 2 删除不必要的索引 3 force index
28 思考题 : 为什么单独delete的话预估行数正常 , 但session a没提交的时候则不正常 ? 因为session a没提交 , 数据是不能删除的 , 相当于有两份数据