欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答

MySQL优化器索引选择迷思。

高鹏(八怪)对本文亦有贡献。

1. 问题描述

群友提出问题,表里有两个列c1、c2,分别为INT、VARCHAR类型,且分别创建了unique key。

SQL查询的条件是 WHERE c1 = ? AND c2 = ?,用EXPLAIN查看执行计划,发现优化器优先选择了VARCHAR类型的c2列索引。

他表示很不理解,难道不应该选择看起来代价更小的INT类型的c1列吗?

2. 问题复现

创建测试表t1:

  1. [root@yejr.run]> CREATE TABLE `t1` (
  2. `c1` int NOT NULL AUTO_INCREMENT,
  3. `c2` int unsigned NOT NULL,
  4. `c3` varchar(20) NOT NULL,
  5. `c4` varchar(20) NOT NULL,
  6. PRIMARY KEY (`c1`),
  7. UNIQUE KEY `k3` (`c3`),
  8. UNIQUE KEY `k2` (`c2`)
  9. ) ENGINE=InnoDB;

利用 mysql_random_data_load 写入一万行数据:

  1. mysql_random_data_load -h127.0.0.1 -uX -pX yejr t1 10000

查看执行计划:

  1. [root@yejr.run]> EXPLAIN SELECT * FROM t1 WHERE
  2. c2 = 1755950419 AND c3 = 'MichaelaAnderson'\G
  3. *************************** 1. row ***************************
  4. id: 1
  5. select_type: SIMPLE
  6. table: t1
  7. partitions: NULL
  8. type: const
  9. possible_keys: k3,k2
  10. key: k3
  11. key_len: 82
  12. ref: const
  13. rows: 1
  14. filtered: 100.00
  15. Extra: NULL

可以看到优化器的确选择了 k3 索引,而非"预期"的 k2 索引,这是为什么呢?

3. 问题分析

其实原因很简单粗暴:优化器认为这两个索引选择的代价都是一样的,只是优先选中排在前面的那个索引而已。

再建一个相同的表 t2,只不过把 k2、k3 的索引创建顺序对调下:

  1. [root@yejr.run]> CREATE TABLE `t2` (
  2. `c1` int NOT NULL AUTO_INCREMENT,
  3. `c2` int unsigned NOT NULL,
  4. `c3` varchar(20) NOT NULL,
  5. `c4` varchar(20) NOT NULL,
  6. PRIMARY KEY (`c1`),
  7. UNIQUE KEY `k2` (`c2`),
  8. UNIQUE KEY `k3` (`c3`)
  9. ) ENGINE=InnoDB;

再查看执行计划:

  1. [root@yejr.run]> EXPLAIN SELECT * FROM t2 WHERE
  2. c2 = 1755950419 AND c3 = 'MichaelaAnderson'\G
  3. *************************** 1. row ***************************
  4. id: 1
  5. select_type: SIMPLE
  6. table: t1
  7. partitions: NULL
  8. type: const
  9. possible_keys: k2,k3
  10. key: k2
  11. key_len: 4
  12. ref: const
  13. rows: 1
  14. filtered: 100.00
  15. Extra: NULL

我们利用 EXPLAIN ANALYZE 来查看下两次执行计划的代价对比:

  1. -- 查看t1表执行计划代价
  2. [root@yejr.run]> EXPLAIN ANALYZE SELECT * FROM t1 WHERE
  3. c2 = 1755950419 AND c3 = 'MichaelaAnderson'\G
  4. *************************** 1. row ***************************
  5. EXPLAIN: -> Rows fetched before execution (cost=0.00..0.00 rows=1) (actual time=0.000..0.000 rows=1 loops=1)
  6. -- 查看t2表执行计划代价
  7. [root@yejr.run]> EXPLAIN ANALYZE SELECT * FROM t2 WHERE c2 = 1755950419 AND c3 = 'MichaelaAnderson'\G
  8. *************************** 1. row ***************************
  9. EXPLAIN: -> Rows fetched before execution (cost=0.00..0.00 rows=1) (actual time=0.000..0.000 rows=1 loops=1)

可以看到,很明显代价都是一样的。

再利用 OPTIMIZE_TRACE 查看执行计划,也能看到两个SQL的代价是一样的:

  1. ...
  2. {
  3. "rows_estimation": [
  4. {
  5. "table": "`t1`",
  6. "rows": 1,
  7. "cost": 1,
  8. "table_type": "const",
  9. "empty": false
  10. }
  11. ]
  12. },
  13. ...

所以,优化器认为选择哪个索引都是一样的,就看哪个索引排序更靠前。

从执行SELECT时的debug trace结果也能佐证:

  1. -- 1 T1表,k3索引在前面
  2. PRIMARY KEY (`c1`),
  3. UNIQUE KEY `k3` (`c3`),
  4. UNIQUE KEY `k2` (`c2`)
  5. T@2: | | | | | | | | opt: (null): starting struct
  6. T@2: | | | | | | | | opt: table: "`t1`"
  7. T@2: | | | | | | | | opt: field: "c3" (C3在前面,因此最后使用k3)
  8. T@2: | | | | | | | | >convert_string
  9. T@2: | | | | | | | | | >alloc_root
  10. T@2: | | | | | | | | | | enter: root: 0x40a8068
  11. T@2: | | | | | | | | | | exit: ptr: 0x4b41ab0
  12. T@2: | | | | | | | | | <alloc_root 304
  13. T@2: | | | | | | | | <convert_string 2610
  14. T@2: | | | | | | | | opt: equals: "'Louise Garrett'"
  15. T@2: | | | | | | | | opt: null_rejecting: 0
  16. T@2: | | | | | | | | opt: (null): ending struct
  17. T@2: | | | | | | | | opt: Key_use: optimize= 0 used_tables=0x0 ref_table_rows= 18446744073709551615 keypart_map= 1
  18. T@2: | | | | | | | | opt: (null): starting struct
  19. T@2: | | | | | | | | opt: table: "`t1`"
  20. T@2: | | | | | | | | opt: field: "c2"
  21. T@2: | | | | | | | | opt: equals: "22896242"
  22. T@2: | | | | | | | | opt: null_rejecting: 0
  23. T@2: | | | | | | | | opt: null_rejecting: 0
  24. T@2: | | | | | | | | opt: (null): ending struct
  25. T@2: | | | | | | | | opt: Key_use: optimize= 0 used_tables=0x0 ref_table_rows= 18446744073709551615 keypart_map= 1
  26. T@2: | | | | | | | | opt: (null): starting struct
  27. T@2: | | | | | | | | opt: table: "`t1`"
  28. T@2: | | | | | | | | opt: field: "c2"
  29. T@2: | | | | | | | | opt: equals: "22896242"
  30. T@2: | | | | | | | | opt: null_rejecting: 0
  31. T@2: | | | | | | | | opt: (null): ending struct
  32. T@2: | | | | | | | | opt: ref_optimizer_key_uses: ending struct
  33. T@2: | | | | | | | | opt: (null): ending struct
  34. -- 2 T2表,k2索引在前面
  35. PRIMARY KEY (`c1`),
  36. UNIQUE KEY `k2` (`c2`),
  37. UNIQUE KEY `k3` (`c3`)
  38. T@2: | | | | | | | | opt: (null): starting struct
  39. T@2: | | | | | | | | opt: table: "`t2`"
  40. T@2: | | | | | | | | opt: field: "c2" C2在前面因此使用k2索引)
  41. T@2: | | | | | | | | opt: equals: "22896242"
  42. T@2: | | | | | | | | opt: null_rejecting: 0
  43. T@2: | | | | | | | | opt: (null): ending struct
  44. T@2: | | | | | | | | opt: Key_use: optimize= 0 used_tables=0x0 ref_table_rows= 18446744073709551615 keypart_map= 1
  45. T@2: | | | | | | | | opt: (null): starting struct
  46. T@2: | | | | | | | | opt: table: "`t2`"
  47. T@2: | | | | | | | | opt: field: "c3"
  48. T@2: | | | | | | | | >convert_string
  49. T@2: | | | | | | | | | >alloc_root
  50. T@2: | | | | | | | | | | enter: root: 0x40a8068
  51. T@2: | | | | | | | | | | exit: ptr: 0x4b41ab0
  52. T@2: | | | | | | | | | <alloc_root 304
  53. T@2: | | | | | | | | <convert_string 2610
  54. T@2: | | | | | | | | opt: equals: "'Louise Garrett'"
  55. T@2: | | | | | | | | opt: null_rejecting: 0
  56. T@2: | | | | | | | | opt: (null): ending struct
  57. T@2: | | | | | | | | opt: ref_optimizer_key_uses: ending struct
  58. T@2: | | | | | | | | opt: (null): ending struct

4. 问题延伸

到这里,我们不禁有疑问,这两个索引的代价真的是一样吗?

就让我们用 mysqlslap 来做个简单对比测试吧:

  1. -- 测试1:对c2列随机point select
  2. mysqlslap -hlocalhost -uroot -Smysql.sock --no-drop --create-schema X -i 3 --number-of-queries 1000000 -q "set @xid = cast(round(rand()*2147265929) as unsigned); select * from t1 where c2 = @xid" -c 8
  3. ...
  4. Average number of seconds to run all queries: 9.483 seconds
  5. ...
  6. -- 测试2:对c3列随机point select
  7. mysqlslap -hlocalhost -uroot -Smysql.sock --no-drop --create-schema X -i 3 --number-of-queries 1000000 -q "set @xid = concat('u',cast(round(rand()*2147265929) as unsigned)); select * from t1 where c3 = @xid" -c 8
  8. ...
  9. Average number of seconds to run all queries: 10.360 seconds
  10. ...

可以看到,如果是走 c3 列索引,耗时会比走 c2 列索引多出来约 7% ~ 9%(在我的环境下测试的结果,不同环境、不同数据量可能也不同)。

看来,MySQL优化器还是有必要进一步提高的哟 :)

测试使用版本:GreatSQL 8.0.25(MySQL 5.6.39结果亦是如此)。

Enjoy GreatSQL

本文由博客一文多发平台 OpenWrite 发布!

MySQL为什么"错误"选择代价更大的索引的更多相关文章

  1. phpMyAdmin - 错误 您应升级到 MySQL 5.5.0 或更高版本,解决办法。。。

    折腾自己的个人网站,装了个数据库管理工具,遇到您应升级到 MySQL 5.5.0 或更高版本... 采用降级phpmyadmin版本的方法解决了: 查找phpmyadmin/libraries/com ...

  2. MySQL数据库错误server_errno=2013的解决

    MySQL数据库错误server_errno=2013的解决 一组MySQL复制环境中的Master意外掉电,重启后Master运行正常,但该复制环境中的其它slave端,Error Log中却抛出的 ...

  3. MySQL 存储过程错误处理

    MySQL  存储过程错误处理 如何使用MySQL处理程序来处理在存储过程中遇到的异常或错误. 当存储过程中发生错误时,重要的是适当处理它,例如:继续或退出当前代码块的执行,并发出有意义的错误消息. ...

  4. 1197多行事务要求更大的max_binlog_cache_size处理与优化

    1197多语句事务要求更大的max_binlog_cache_size报错   binlog_cache_size:为每个session 分配的内存,在事务过程中用来存储二进制日志的缓存,提高记录bi ...

  5. MySQL与PostgreSQL相比哪个更好?

    网上已经有很多拿PostgreSQL与MySQL比较的文章了,这篇文章只是对一些重要的信息进行下梳理.在开始分析前,先来看下这两张图: MySQL MySQL声称自己是最流行的开源数据库.LAMP中的 ...

  6. 梭子鱼:APT攻击是一盘更大的棋吗?

    随着企业对IT的依赖越来越强,APT攻击可能会成为一种恶意打击竞争对手的手段.目前,APT攻击目标主要有政治和经济目的两大类.而出于经济目的而进行的APT攻击可以获取竞争对手的商业信息,也可使用竞争对 ...

  7. 对比MySQL,什么场景MongoDB更适用

    原文链接: http://page.factj.com/blog/p/4078 MongoDB已经流行了很长一段时间,相对于MySQL,究竟什么场景更需要用MongoDB?下面是一些总结. 更高的写入 ...

  8. Atitit.软件GUIbutton与仪表盘--db数据库区--导入mysql sql错误的解决之道

    Atitit.软件GUIbutton与仪表盘--db数据库区--导入mysql sql错误的解决之道 Keyword::截取文本文件后部分 查看提示max_allowed_packet限制 Targe ...

  9. mysql 1053错误,无法启动的解决方法

    mysql 1053错误,无法启动的解决方法 windows2003服务器中,服务器重启后Mysql却没有启动,手动启动服务时提示1053错误. 尝试了以下方法,终于解决. 1.在DOS命令行使用 第 ...

随机推荐

  1. 149_1秒获取Power BI Pro帐号

    一.背景 当你来到这篇文章的时候,我想你已经在网上搜索了一圈了.网上有一大把教你如何注册Power BI帐号的方法,我们这里就不在赘述了.因为各种因素的限制确实比较麻烦.我们直接提供Power BI ...

  2. 126_Power BI中使用DAX计算股票RSI及股票均线相关

    博客:www.jiaopengzi.com 焦棚子的文章目录 请点击下载附件 一.背景 前些日子,有朋友在交流股票RSI用DAX处理的问题,由于RSI股票软件的算法几乎都是需要用到股票从上市第一天开始 ...

  3. vue中使用echarts的两种方法

    在vue中使用echarts有两种方法一.第一种方法1.通过npm获取echarts npm install echarts --save 2.在vue项目中引入echarts 在 main.js 中 ...

  4. 一文学完Linux常用命令

    一.Linux 终端命令格式 1.终端命令格式 完整版参考链接:Linux常用命令完整版 command [-options] [parameter] 说明: command : 命令名,相应功能的英 ...

  5. Property or method "xxx" is not defined on the instance but referenced during render

    是xxx中的data写成date了,因此报错. 这个错误属于粗心

  6. 『忘了再学』Shell基础 — 24、Shell正则表达式的使用

    目录 1.正则表达式说明 2.基础正则表达式 3.练习 (1)准备工作 (2)*练习 (3).练习 (4)^和$练习 (5)[]练习 (6)[^]练习 (7)\{n\}练习 (8)\{n,\}练习 ( ...

  7. Machine Learning With Go 第4章:回归

    4 回归 之前有转载过一篇文章:容量推荐引擎:基于吞吐量和利用率的预测缩放,里面用到了基本的线性回归来预测容器的资源利用情况.后面打算学一下相关的知识,译自:Machine Learning With ...

  8. 使用Rclone将Onedirve挂载到Linux本地

    1. centos挂载onedrive时, 需要安装fuse. # 安装fuse yum -y install fuse 2. 安装完fuse后使用rclone进行挂载 #创建挂载目录 mkdir - ...

  9. 【freertos】012-事件标志概念和实现细节

    目录 前言 12.1 实现事件机制的预备知识 12.1.1 守护任务 12.1.2 事件的不确定性 12.1.3 事件组的报文 12.2 事件概念 12.3 事件用途参考 12.4 事件实现原理简述 ...

  10. 22.LVS+Keepalived 高可用群集

    LVS+Keepalived 高可用群集 目录 LVS+Keepalived 高可用群集 keepalived工具介绍 Keepalived实现原理剖析 VRRP(虚拟路由冗余协议) VRRP 相关术 ...