18 | 为什么这些SQL语句逻辑相同,性能却差异巨大?
该思维导图由 AI 生成,仅供参考
案例一:条件字段函数操作
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了MySQL中相似逻辑的SQL语句却存在巨大性能差异的原因。通过具体案例分析和图示,解释了对索引字段进行函数操作可能导致性能下降的情况,以及隐式类型转换对性能的影响。文章指出,对索引字段做函数操作可能破坏索引值的有序性,导致优化器放弃走树搜索功能,从而进行全表扫描。此外,隐式字符编码转换也会导致类似问题。作者提供了两种优化方法:修改字段字符集或修改SQL语句。总结来说,读者可以从中了解SQL语句性能差异的原因,以及如何避免这些问题,从而更好地优化数据库性能。文章深入浅出地解释了这些现象背后的原理和规则,为读者提供了宝贵的优化经验。
《MySQL 实战 45 讲》,新⼈⾸单¥68
全部留言(158)
- 最新
- 精选
- 冠超置顶非常感谢老师分享的内容,实打实地学到了。这里提个建议,希望老师能介绍一下设计表的时候要怎么考虑这方面的知识哈😊
作者回复: 是这样的,其实我们整个专栏大部分的文章,最后都是为了说明 “怎么设计表”、“怎么考虑优化SQL语句” 但是因为这个不是一成不变的,很多是需要考虑现实的情况, 所以这个专栏就是想把对应的原理说一下,这样大家在应对不同场景的时候,可以组合来考虑。 也就是说没有一段话可以把“怎么设计表”讲清楚(或者说硬写出来很可能就是一些general的没有什么针对性作用的描述) 你可以把你的业务背景抽象说下,我们来具体讨论吧
2019-01-28230 - 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-1857 - 可凡不凡置顶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-252122 - 赖阿甘置顶“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-241242 - 老杨同志置顶感谢老师鼓励,我本人工作时间比较长,有一定的基础,听老师的课还是收获很大。每次公司内部有技术分享,我都去听课,但是多数情况,一两个小时的分享,就只有一两句话受益。老师的每篇文章都能命中我的知识盲点,感觉太别爽。 对应今天的隐式类型转换问题也踩过坑。 我们有个任务表记录待执行任务,表结构简化后如下: 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-2430176 - 探索无止境老师,有道面试题困扰了很久,求指教!题目是这样的,a表有100条记录,b表有10000条记录,两张表做关联查询时,是将a表放前面效率高,还是b表放前面效率高?网上各种答案,但感觉都没有十分的说服力,期待老师的指点!
作者回复: (这题目改成100万禾10000万比较好) 如果是考察语句写法,这两个表谁放前面都一样,优化器会调整顺序选择合适的驱动表; 如果是考察优化器怎么实现的,你可以这么想,每次在树搜索里面做一次查找都是log(n), 所以对比的是100*log(10000)和 10000*log(100)哪个小,显然是前者,所以结论应该是让小表驱动大表。
2019-01-1314222 - geraltlaush索引字段不能进行函数操作,但是索引字段的参数可以玩函数,一言以蔽之
作者回复: 精辟😄
2018-12-249108 - 风轨刚试了文中穿插得思考题:当主键是整数类型条件是字符串时,会走索引。 文中提到了当字符串和数字比较时会把字符串转化为数字,所以隐式转换不会应用到字段上,所以可以走索引。 另外,select 'a' = 0 ; 的结果是1,说明无法转换成数字的字符串都被转换成0来处理了。
作者回复: 👍🏿
2018-12-24459 - crazyone老师你好,我在执行explain的时候,发现extra 里面 有using where,using index ,using index condition 能具体讲下这几个的区别吗?
作者回复: Using index是覆盖索引 Using index condition 是索引下推
2018-12-26551 - 饭粒感觉要使用索引就不能“破坏”索引原有的顺序,这节的函数操作,隐式转换都“破坏”了原有的顺序。前一节的select * from t where city in in (“杭州”," 苏州 ") order by name limit 100; 同样是破坏了 (city,name) 联合索引的递增顺序,类似的还有使用联合索引,一个字段DESC,一个ASC。
作者回复: 👍 总结得很好 “顺势而查”才能用上索引😆
2019-02-2527