MySQL 实战 45 讲
林晓斌
网名丁奇,前腾讯云数据库负责人
224873 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
实践篇 (37讲)
特别放送 (1讲)
结课测试 (1讲)
MySQL 实战 45 讲
15
15
1.0x
00:00/00:00
登录|注册

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

修改字符集或SQL语句以避免字符编码转换
字符编码转换导致全表扫描
字符集转换规则
修改SQL语句或字段类型以避免类型转换
类型转换导致全索引扫描
数据类型转换规则
改写SQL语句以利用索引
函数操作破坏索引的有序性
索引的有序性
利用主键索引的有序性
使用rowid
重新整理数据
优化器的行为分析
修改SQL语句或字段类型
分析问题原因
手动改写SQL语句以利用索引
优化器放弃走树搜索功能
对索引字段做函数操作
案例三:隐式字符编码转换
案例二:隐式类型转换
案例一:条件字段函数操作
性能问题解决方法分享
性能问题解决思路
优化器的"偷懒"行为
性能差异巨大的SQL语句问题

该思维导图由 AI 生成,仅供参考

在 MySQL 中,有很多看上去逻辑相同,但性能却差异巨大的 SQL 语句。对这些语句使用不当的话,就会不经意间导致整个数据库的压力变大。
我今天挑选了三个这样的案例和你分享。希望再遇到相似的问题时,你可以做到举一反三、快速解决问题。

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

假设你现在维护了一个交易系统,其中交易记录表 tradelog 包含交易流水号(tradeid)、交易员 id(operator)、交易时间(t_modified)等字段。为了便于描述,我们先忽略其他字段。这个表的建表语句如下:
mysql> 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;
假设,现在已经记录了从 2016 年初到 2018 年底的所有数据,运营部门有一个需求是,要统计发生在所有年份中 7 月份的交易记录总数。这个逻辑看上去并不复杂,你的 SQL 语句可能会这么写:
mysql> select count(*) from tradelog where month(t_modified)=7;
由于 t_modified 字段上有索引,于是你就很放心地在生产库中执行了这条语句,但却发现执行了特别久,才返回了结果。
如果你问 DBA 同事为什么会出现这样的情况,他大概会告诉你:如果对字段做了函数计算,就用不上索引了,这是 MySQL 的规定。
现在你已经学过了 InnoDB 的索引结构了,可以再追问一句为什么?为什么条件是 where t_modified='2018-7-1’的时候可以用上索引,而改成 where month(t_modified)=7 的时候就不行了?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了MySQL中相似逻辑的SQL语句却存在巨大性能差异的原因。通过具体案例分析和图示,解释了对索引字段进行函数操作可能导致性能下降的情况,以及隐式类型转换对性能的影响。文章指出,对索引字段做函数操作可能破坏索引值的有序性,导致优化器放弃走树搜索功能,从而进行全表扫描。此外,隐式字符编码转换也会导致类似问题。作者提供了两种优化方法:修改字段字符集或修改SQL语句。总结来说,读者可以从中了解SQL语句性能差异的原因,以及如何避免这些问题,从而更好地优化数据库性能。文章深入浅出地解释了这些现象背后的原理和规则,为读者提供了宝贵的优化经验。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《MySQL 实战 45 讲》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(158)

  • 最新
  • 精选
  • 冠超
    置顶
    非常感谢老师分享的内容,实打实地学到了。这里提个建议,希望老师能介绍一下设计表的时候要怎么考虑这方面的知识哈😊

    作者回复: 是这样的,其实我们整个专栏大部分的文章,最后都是为了说明 “怎么设计表”、“怎么考虑优化SQL语句” 但是因为这个不是一成不变的,很多是需要考虑现实的情况, 所以这个专栏就是想把对应的原理说一下,这样大家在应对不同场景的时候,可以组合来考虑。 也就是说没有一段话可以把“怎么设计表”讲清楚(或者说硬写出来很可能就是一些general的没有什么针对性作用的描述) 你可以把你的业务背景抽象说下,我们来具体讨论吧

    2019-01-28
    2
    30
  • 700
    置顶
    老师您好,有个问题恳请指教。背景如下,我长话短说: mysql>select @@version; 5.6.30-log CREATE TABLE `t1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `plan_id` int(11) NOT NULL DEFAULT '0' , PRIMARY KEY (`id`), KEY `userid` (`user_id`) USING BTREE, KEY `idx_planid` (`plan_id`) ) ENGINE=InnoDB DEFAULT CHARSET=gb2312; CREATE TABLE `t3` ( `id` int(11) NOT NULL AUTO_INCREMENT, `status` int(4) NOT NULL DEFAULT '0', `ootime` varchar(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_xxoo` (`status`,`ootime`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; t1 和 t3 表的字符集不一样 sql 执行计划如下: explain SELECT t1.id, t1.user_id FROM t1, t3 WHERE t1.plan_id = t3.id AND t3.ootime < UNIX_TIMESTAMP('2022-01-18') +----+-------------+-------+-------+---------------+--------------+---------+--------------+-------+----------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+--------------+---------+--------------+-------+----------------------------------------+ | 1 | SIMPLE | t3 | index | PRIMARY | idx_xxoo | 51 | NULL | 39106 | Using where; Using index | | 1 | SIMPLE | t1 | ref | idx_planid | idx_planid | 4 | t3.id | 401 | Using join buffer (Batched Key Access) | +----+-------------+-------+-------+---------------+--------------+---------+--------------+-------+----------------------------------------+ 我的疑惑是 1)t3 的 status 没出现在 where 条件中,但执行计划为什么用到了 idex_xxoo 索引? 2)为什么 t3.ootime 也用到索引了,从 key_len 看出。t3.ootime 是 varchar 类型的,而 UNIX_TIMESTAMP('2022-01-18') 是数值,不是发生了隐式转换吗? 请老师指点。

    作者回复: 这个查询语句会对t3做全索引扫描,是使用了索引的,只是没有用上快速搜索功能

    2019-01-18
    5
    7
  • 可凡不凡
    置顶
    1.老师好 2.如果在用一个 MySQL 关键字做字段,并且字段上索引,当我用这个索引作为唯一查询条件的时候 ,会 造 成隐式的转换吗? 例如:SELECT * FROM b_side_order WHERE CODE = 332924 ; (code 上有索引) 3. mysql5.6 code 上有索引 intime 上没有索引 语句一: SELECT * FROM b_side_order WHERE CODE = 332924 ; 语句二; UPDATE b_side_order SET in_time = '2018-08-04 08:34:44' WHERE 1=2 or CODE = 332924; 这两个语句 执行计划走 select 走了索引,update 没有走索引 是执行计划的bug 吗??

    作者回复: 1. 你好😄 2. CODE不是关键字呀, 另外优化器选择跟关键字无关哈,关键字的话,要用 反‘ 括起来 3. 不是bug, update如果把 or 改成 and , 就能走索引😄

    2018-12-25
    21
    22
  • 赖阿甘
    置顶
    “mysql>select l.operator from tradelog l , trade_detail d where d.tradeid=l.tradeid and d.id=4;” 图6上面那句sql是不是写错了。d.tradeid=l.tradeid是不是该写成l.tradeid = d.tradeid?不然函数会作用在索引字段上,就只能全表扫描了

    作者回复: 这个问题不是等号顺序决定的哈 好问题

    2018-12-24
    12
    42
  • 老杨同志
    置顶
    感谢老师鼓励,我本人工作时间比较长,有一定的基础,听老师的课还是收获很大。每次公司内部有技术分享,我都去听课,但是多数情况,一两个小时的分享,就只有一两句话受益。老师的每篇文章都能命中我的知识盲点,感觉太别爽。 对应今天的隐式类型转换问题也踩过坑。 我们有个任务表记录待执行任务,表结构简化后如下: 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='任务表'; task_rfid 是业务主键,当然都是数字,查询时使用sql: select * from task where task_rfid =123; 其实这个语句也有隐式转换问题,但是待执行任务只有几千条记录,并没有什么感觉。 这个表还有个对应的历史表,数据有几千万 忽然有一天,想查一下历史记录,执行语句 select * from task_history where task_rfid =99; 直接就等待很长时间后超时报错了。 如果仔细看,其实我的表没有task_rfid 索引,写成task_rfid =‘99’也一样是全表扫描。 运维时的套路是,猜测主键task_id的范围,怎么猜,我原表有creat_time字段,我会先查 select max(task_id) from task_history 然后再看看 select * from task_history where task_id = maxId - 10000的时间,估计出大概的id范围。然后语句变成 select * from task_history where task_rfid =99 and id between ? and ?;

    作者回复: 你最后这个id预估,加上between , 有种神来之笔的感觉😄 感觉隐约里面有二分法的思想 👍🏿

    2018-12-24
    30
    176
  • 探索无止境
    老师,有道面试题困扰了很久,求指教!题目是这样的,a表有100条记录,b表有10000条记录,两张表做关联查询时,是将a表放前面效率高,还是b表放前面效率高?网上各种答案,但感觉都没有十分的说服力,期待老师的指点!

    作者回复: (这题目改成100万禾10000万比较好) 如果是考察语句写法,这两个表谁放前面都一样,优化器会调整顺序选择合适的驱动表; 如果是考察优化器怎么实现的,你可以这么想,每次在树搜索里面做一次查找都是log(n), 所以对比的是100*log(10000)和 10000*log(100)哪个小,显然是前者,所以结论应该是让小表驱动大表。

    2019-01-13
    14
    222
  • geraltlaush
    索引字段不能进行函数操作,但是索引字段的参数可以玩函数,一言以蔽之

    作者回复: 精辟😄

    2018-12-24
    9
    108
  • 风轨
    刚试了文中穿插得思考题:当主键是整数类型条件是字符串时,会走索引。 文中提到了当字符串和数字比较时会把字符串转化为数字,所以隐式转换不会应用到字段上,所以可以走索引。 另外,select 'a' = 0 ; 的结果是1,说明无法转换成数字的字符串都被转换成0来处理了。

    作者回复: 👍🏿

    2018-12-24
    4
    59
  • crazyone
    老师你好,我在执行explain的时候,发现extra 里面 有using where,using index ,using index condition 能具体讲下这几个的区别吗?

    作者回复: Using index是覆盖索引 Using index condition 是索引下推

    2018-12-26
    5
    51
  • 饭粒
    感觉要使用索引就不能“破坏”索引原有的顺序,这节的函数操作,隐式转换都“破坏”了原有的顺序。前一节的select * from t where city in in (“杭州”," 苏州 ") order by name limit 100; 同样是破坏了 (city,name) 联合索引的递增顺序,类似的还有使用联合索引,一个字段DESC,一个ASC。

    作者回复: 👍 总结得很好 “顺势而查”才能用上索引😆

    2019-02-25
    27
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部