SQL 查询优化器缺陷有哪些？性能差异有多大？

SQL 查询优化器缺陷有哪些？

谁也没料到，SQL 查询优化器也“拉胯”！

扫描一条微信，就能发现数不清宣称 SQL 优化效果拔群的神器，恨不得有了它们，SQL 性能就能原地起飞。但真的是这样吗？

我来泼一盆冷水：SQL 查询优化器本身就存在不少缺陷，根本无法保证次次都能跑得最优。

缺陷 1：开销过大，一不小心就死机

情景复现：

数据库里有一张 10 亿条数据的表，小明写了个查询语句想取其中 10 万条：

sql

SELECT FROM my_table WHERE id > 1000000;

正常情况下，优化器只需扫描 10 万条数据，岂料优化器发疯，偏要扫描全部 10 亿条数据，把服务器搞死机了。

缺陷 2：走马观花，视而不见

情景复现：

小红想查询订单表中最近 30 天内销售额排名前 10 的商品，结果优化器直接无视掉了日期范围限制，照样把所有商品的销售额都算了一遍，白白浪费了时间。

缺陷 3：灵活变通？这是瞎凑吗？

情景复现：

小刚的查询条件中包含两个日期：start_date 和 end_date。当 start_date 为空时，优化器自作聪明，把条件替换成了 end_date 不为空，导致查询结果多了几百万条废数据。

缺陷 4：只顾当下，不看未来

情景复现：

小美查询了订单表，优化器刚给出的执行计划用的索引是 idx_order_id，但接下来又查询了客户表，这时候用 idx_customer_id 索引显然更好。结果优化器一成不变，还是用的 idx_order_id。

性能差异有多大？

差距能有多大？那可是天文数字！

缺陷严重时，优化器选出的执行计划和最优执行计划的效率差异，可以用秒和小时来衡量。不信？实例奉上：

案例 1：查询 10 亿条数据

性能差异：2400 倍！

案例 2：取前 100 条数据

性能差异：10000 倍！

所以，SQL 查询优化器，你信它个鬼！

真正的 SQL 优化之路

既然优化器不可靠，难道我们就只能认命了吗？当然不！

正确的 SQL 优化之路，是内外兼修。

内功修炼：

1. 理解 SQL 语法：熟练 SQL 语法，才能写出结构清晰、执行效率高的语句。

2. 掌握索引原理：索引是性能优化的利器，深入理解索引，才能恰到好处地创建和维护索引。

3. 分析执行计划：优化器给你执行计划，你要学会看懂、分析，找出不合理之处。

外部工具：

1. SQL 调优工具：市面上有各种 SQL 调优工具，可以帮助你分析 SQL 语句、找出性能瓶颈。

2. 数据库监控工具：通过监控数据库，你可以发现 SQL 语句的执行情况，找出经常出现性能问题的语句。

互动

1. 你在 SQL 优化中遇到过哪些奇葩

2. 你最喜欢的 SQL 调优工具有哪些？

3. 对于 SQL 查询优化器，你有什么想吐槽或建议的吗？

上一篇：一键优化系统进程，怎么清理掉不必要的缓存文件？

下一篇：免费SEO关键词工具好用吗，能帮搜索引擎收录网站内容吗？