SQL 优化艺术：从理论到实战的深度指南

🚀 SQL 优化艺术：从理论到实战的深度指南#“我的应用明明用户不多，怎么数据库就慢得像拖拉机？”

“这个查询昨天还跑得好好的，今天怎么就卡死了？”

兄弟们，是不是经常有这种感觉？SQL 性能问题就像幽灵，时隐时现，难以捉摸。网上背了一堆“军规”，什么“不要用 Select *”，什么“索引必须安排上”，但一到真实战场就抓瞎。

今天，咱们就彻底告别那些枯燥的理论和八股文。我们直接从真实业务场景出发，用“老司机”的视角，一层层剥开 SQL 优化的洋葱。这篇文章不仅会涵盖那些让索引失效的经典“天坑”，还会深入到查询的执行机制、排序和分组的性能奥秘。

更重要的是，咱们会全程对比目前最火的两个开源关系型数据库—— MySQL 和 PostgreSQL。你会发现，它们在处理同一个问题时，思路和“脾气”可能完全不同。这不仅能帮你解决眼前的问题，更能让你在未来的技术选型中，做出更明智的决策。

准备好了吗？系好安全带，咱们发车！🚌

Part 1: 优化的基石 - 万变不离其宗#1.1. 优化第一步：不是加索引，而是看“病历”#别上来就说 “加索引”！老司机都是有套路的：

先看病 (慢查询日志)：开启 slow_query_log，找出是谁在拖后腿。拍片子 (Explain)：用 EXPLAIN 看看它到底是怎么执行的。开药方：索引优化：该加的加，该改的改。SQL重写：join 太多？子查询太深？改！架构调整：读写分离、分库分表（那是最后的大招）。💡 小贴士：别忘了定期清理没用的索引，索引多了这表“写入”就废了。

1.2. EXPLAIN 解读核心：抓住 type, key, Extra#别被那一堆参数吓到了，盯着这 3 个看就够了：

type (连接类型)：这是最重要的指标！

🤩 牛逼：system > const > eq_ref (主键/唯一索引)🙂 凑合：ref (非唯一索引) > range (范围查询)😱 完蛋：index (全索引扫描) > ALL (全表扫描，准备跑路吧)key (实际用到的索引)：如果是 NULL，说明你在裸奔，赶紧加索引。

Extra (额外信息)：

🚨 Using filesort：警报！ MySQL 在内存/磁盘里自己排序了，没走索引排序，慢！🚨 Using temporary：警报！ 用了临时表，通常出现在 DISTINCT 或 GROUP BY，巨慢！✅ Using index：好耶！ 覆盖索引，不需要回表，完美。1.3. 案例：你的第一个全表扫描 (ALL) 与第一次索引优化#光说不练假把式。我们用下载的测试数据，亲手体验一下从“拖拉机”到“法拉利”的快感。

场景：我们要根据用户的邮箱地址查找用户信息。

第一步：裸奔查询

我们的 users 表刚创建，email 字段上没有任何索引。

EXPLAIN SELECT * FROM users WHERE email = 'user_100@example.com';MySQL EXPLAIN 结果：

你会看到一行关键信息：type: ALL。

type: ALL：这告诉我们，MySQL 为了找到这一个邮箱，不得不把 users 表里的每一行都翻出来看一遍。这就是全表扫描。现在表里只有1000条数据，感觉不明显。想象一下如果有一千万条，那将是一场灾难。PostgreSQL EXPLAIN 结果：

QUERY PLAN

---------------------------------------------------------------

Seq Scan on users (cost=0.00..25.00 rows=1 width=118)

Filter: (email = 'user_100@example.com'::text)Seq Scan on users：Seq 就是 Sequential（顺序的），Seq Scan 等同于 MySQL 的 ALL，表示对 users 表进行顺序扫描，也就是全表扫描。第二步：创建索引

现在，我们给 email 字段加上索引。

-- MySQL

CREATE INDEX idx_email ON users (email);

-- PostgreSQL

CREATE INDEX idx_email ON users (email);第三步：再次伟大

再执行一次相同的查询：

EXPLAIN SELECT * FROM users WHERE email = 'user_100@example.com';MySQL EXPLAIN 结果：

type: ref：类型变成了 ref！这表示 MySQL 通过索引，像查字典一样，非常精确地找到了匹配的行。key: idx_email：它明确告诉我们，它使用了刚刚创建的 idx_email 索引。PostgreSQL EXPLAIN 结果：

QUERY PLAN

-------------------------------------------------------------------------------------

Index Scan using idx_email on users (cost=0.29..8.31 rows=1 width=118)

Index Cond: (email = 'user_100@example.com'::text)Index Scan using idx_email：扫描类型变成了 Index Scan，并且明确使用了 idx_email 索引。效率和 ref 类似，都是质的飞跃。这就是最基础也是最核心的一次优化。我们通过 EXPLAIN 发现了问题 (ALL/Seq Scan)，并通过创建索引解决了它。

Part 2: 索引失效的“七宗罪” - 为什么我的索引总在“摸鱼”？#2.1. 隐式转换：MySQL的“温柔一刀” vs PostgreSQL的“直接报错”#这是 90% 的开发都会踩的坑！

场景：phone 字段是 varchar 类型，你查的时候给了个数字。

-- ❌ 索引失效！全表扫描！

SELECT * FROM users WHERE phone = 13800138000;

-- ✅ 索引生效

SELECT * FROM users WHERE phone = '13800138000';原因：MySQL 发现类型不对，会偷偷把字符串转成数字再比对。这意味着它要对每一行数据都做一次转换运算，索引自然就废了。

⚠️ 数据库差异避坑 (MySQL vs PostgreSQL)：

MySQL: 默默承受，帮你隐式转换，然后索引失效，性能暴跌。PostgreSQL: 脾气暴躁，直接报错 operator does not exist。其实我觉得 PG 这样挺好，起码你立刻就知道错了。2.2. 函数“包装”：WHERE YEAR(date) = 2024 为何是性能杀手？#场景：我想查2024年的数据。

-- ❌ 索引失效

-- 对字段用了 YEAR() 函数，索引就看不懂了

SELECT * FROM orders WHERE YEAR(create_time) = 2024;原因：索引存的是具体的日期，不是年份。你对字段做运算，MySQL 就得把所有行都算一遍。

解法：把函数移到等号右边，或者改写成范围查询。

-- ✅ 索引生效

SELECT * FROM orders

WHERE create_time >= '2024-01-01'

AND create_time < '2025-01-01';2.3. LIKE '%keyword%': 何时走，何时不走，以及如何拯救？#LIKE '%张三'：全表扫描。前缀都不确定，索引树没法找。LIKE '张三%'：走索引！这就叫“最左前缀”。问：那我就想查 “包含张三” (%张三%) 怎么办？

答：

覆盖索引：如果你只查 id 和 name，且它俩有联合索引，勉强能走个全索引扫描 (index)，比全表扫描 (ALL) 快点。全文索引：MySQL 5.7+ 和 PG 都支持 Fulltext Search。大招：出门左转找 Elasticsearch。2.4. OR 的挣扎：索引合并 (Index Merge) 是救星还是陷阱？#以前的教程会告诉你：别用 OR，用 UNION。但现在变了。

Index Merge (索引合并)：

如果 id 有索引，phone 也有索引。

SELECT * FROM users WHERE id = 1 OR phone = '138000';现在的数据库（MySQL 5.0+ / PG）都很聪明，它会分别走两个索引，然后把结果合并起来。在 Explain 里你会看到 type: index_merge。

但是！ 还是建议尽量用 UNION 或 UNION ALL，因为 Index Merge 并不总是触发，而且合并也是有开销的。

2.5. NULL 的传说与真相：IS NULL 到底会不会走索引？#这是一个经典的都市传说：“索引不存 NULL”。

辟谣：

MySQL (InnoDB): 索引是记录 NULL 值的。IS NULL 和 IS NOT NULL 都可以走索引。PostgreSQL: 也支持，还可以指定 NULLS FIRST 或 NULLS LAST。但是：如果你的列大部分都是 NULL，或者大部分都不是 NULL，优化器可能会觉得“走索引还不如全表扫呢”，从而放弃索引。

2.6. 联合索引的“最左前缀”原则：图解“断桥”效应#想象一下，你建了个联合索引 (a, b, c)。

这就像你建了个楼梯，第一级是 a，第二级是 b，第三级是 c。

查 a？ 走索引（上了一级台阶）。查 a 和 b？ 走索引（上了两级）。查 b 和 c？ 不走索引！你第一级台阶都没上，怎么上第二级？（这就是断桥）。查 a 和 c？ 只走 a 的索引。c 用不上，因为中间 b 断了。PostgreSQL 特技：PG 有些索引类型（如 GIN）或者在特定查询规划下，跳跃扫描能力比 MySQL 强一些，但遵循最左原则依然是最佳实践。

2.7. 字符集与排序规则不一致的隐形坑#这是一个极其隐蔽的坑，尤其是多表 JOIN 时。

场景：orders 表用的是 utf8mb4，而 order_logs 表不小心用了 utf8。你现在要 JOIN 它们。

SELECT *

FROM orders o

JOIN order_logs ol ON o.order_id = ol.order_id;结果：即使 order_id 两边都有索引，MySQL 也可能无法使用其中一个或两个表的索引，因为它需要在连接时进行动态的字符集转换。

原因：不同的字符集意味着不同的编码和排序规则。MySQL 无法确定 utf8 的 ‘a’ 是不是等于 utf8mb4 的 ‘a’，所以它放弃了使用索引，改为逐行比较。

解法：保持所有关联字段的字符集和排序规则（Collation）绝对一致！

-- 检查表的字符集

SHOW CREATE TABLE orders;

-- 修改表的字符集

ALTER TABLE order_logs CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;⚠️ 数据库差异避坑 (MySQL vs PostgreSQL)：

MySQL: 对字符集非常敏感，不一致基本就等于性能灾难。PostgreSQL: 字符集管理更为严格和统一，通常在数据库级别设定，不太容易出现表与表之间不一致的情况。但如果通过 dblink 等方式连接异构数据库，同样的问题依然存在。Part 3: 排序、分组与聚合 - 榨干查询性能#3.1. ORDER BY 与 Using filesort: 如何让排序“免费”？#Using filesort 不是说真的去读写文件，而是说无法利用索引顺序，需要在内存（sort buffer）中重新排序。

如何避免？

如果你想 ORDER BY create_time，那就给 create_time 加个索引。索引本身就是排好序的，拿出来就是有序的，根本不需要再排！

联合索引坑位：

索引 (a, b)。

ORDER BY a, b -> ✅ 完美。ORDER BY b -> ❌ 必须先定 a 才能按 b 排。WHERE a = 10 ORDER BY b -> ✅ a 定了，b 自然就是有序的。3.2. GROUP BY 的优化之路：从隐式排序到索引覆盖#GROUP BY 本质上是：先排序，再分组。

所以它默认会触发排序（MySQL 8.0 之前）。

优化：

加索引：和 Order By 一样，如果字段有序，分组就极快。禁止排序：如果你不在乎组的顺序，加个 ORDER BY NULL（MySQL 8.0 之前有效，8.0 以后默认不隐式排序了）。PG 特性：PostgreSQL 对 Group By 的优化通常比 MySQL 智能一点，但索引依然是王道。3.3. COUNT(*) vs COUNT(1) vs COUNT(column): 世纪之争的最终答案#COUNT(字段)：最慢。它要把它拿出来，判断是不是 NULL，不是 NULL 才计数。COUNT(1)：快。不需要取出字段，但需要扫描行。COUNT(*)：最快（理论上）。MySQL 专门对此做了优化，它不取值，直接按行累加。注意：

MyISAM：COUNT(*) 是瞬时的（存了总数）。InnoDB / PostgreSQL：都要老老实实全表扫描（因为有 MVCC，不知道哪些行对当前事务可见）。Part 4: JOIN 与子查询 - 表关联的艺术#4.1. 小表驱动大表：Nested-Loop, Hash Join 的背后逻辑#原则：拿小表去鞭策大表。

-- users 表（小），orders 表（大）

SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id;MySQL 会拿着 users 里的 id，去 orders 的索引里一个个找。

如果反过来，拿 orders 驱动 users，那你得在 users 索引里查几千万次，直接爆炸。

Simple Nested-Loop Join (SNLJ) 早就过时了，现在都是 Block Nested-Loop (BNL) 或者 Hash Join (MySQL 8.0+ / PG)。但“小表驱动大表”的核心思想永不过时。

4.2. IN vs EXISTS: 谁更胜一筹？场景说了算#这要看谁大谁小：

子查询表大，外层表小 -> 用 EXISTS。子查询表小，外层表大 -> 用 IN。-- 子查询结果集小，IN 把它缓存起来，外层大表扫一遍匹配一下，快。

SELECT * FROM big_table WHERE id IN (SELECT id FROM small_table);

-- 子查询结果集大，EXISTS 相当于对外层每一行做个校验，外层小，校验次数少，快。

SELECT * FROM small_table WHERE EXISTS (SELECT 1 FROM big_table WHERE ...);4.3. LEFT JOIN 优化：WHERE 条件放在 ON 后还是 WHERE 子句里的巨大差异#这是决定 LEFT JOIN 行为的关键，很多人都会搞混。

结论先行：

ON: 先按条件过滤右表，再拿左表去匹配。不管匹不匹配得上，左表都会全部保留。WHERE: 两张表先按 ON 的条件 JOIN 起来，形成一个临时的中间表，然后再用 WHERE 对这个中间表进行过滤。场景：找出所有用户，以及他们“已完成”的订单。

-- 写法1: 条件在 ON

SELECT u.name, o.status

FROM users u

LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'completed';

-- 写法2: 条件在 WHERE

SELECT u.name, o.status

FROM users u

LEFT JOIN orders o ON u.id = o.user_id

WHERE o.status = 'completed' OR o.status IS NULL;

-- (注意：因为是LEFT JOIN，未匹配到的用户订单状态是NULL，也要包含进来)结果天差地别：

写法1 (ON): 会列出所有用户。有“已完成”订单的，会显示订单状态；没有的，订单状态显示 NULL。写法2 (WHERE): LEFT JOIN 会退化成 INNER JOIN！WHERE 子句会把那些 o.status 为 NULL 的行（也就是没有订单的用户）给过滤掉。性能影响：

ON 里的条件如果能用到右表的索引，可以大大减少需要连接的数据量，性能更高。WHERE 是在连接完成后才过滤，如果中间结果集很大，性能会很差。一句话总结：想先过滤右表再连接，用 ON；想在连接后的总结果里过滤，用 WHERE，但要小心 LEFT JOIN 变成 INNER JOIN 的坑。

4.4. 案例：三张表以上的 JOIN 如何排查性能瓶颈？#当 JOIN 超过三张表，EXPLAIN 的结果就会变得复杂。这时需要有策略地进行分析。

场景：查询购买了“手机”这个分类下的商品的所有用户的名字和邮箱。

SELECT u.name, u.email

FROM users u

JOIN orders o ON u.id = o.user_id

JOIN order_items oi ON o.id = oi.order_id

JOIN products p ON oi.product_id = p.id

JOIN categories c ON p.category_id = c.id

WHERE c.name = '手机';排查步骤：

看驱动顺序：EXPLAIN 结果的第一行就是驱动表。MySQL 通常会选择它认为最小的表作为驱动表。在这个例子里，应该是 categories 表（因为 WHERE 条件先作用于它）。逐个 JOIN 分析：categories JOIN products：EXPLAIN 看 p 表的 type 是不是 ref 或 eq_ref，key 是不是用到了 category_id 索引。…然后 JOIN order_items：EXPLAIN 看 oi 表的 type 是不是 ref，key 是不是用到了 product_id 索引。…然后 JOIN orders：看 o 表……最后 JOIN users：看 u 表…找到瓶颈：如果在某一步 JOIN 的 type 突然变成了 ALL (全表扫描) 或 index (全索引扫描)，那问题就出在这里！说明这个 JOIN 的关联字段没有合适的索引。拆解大法：

如果 EXPLAIN 太复杂，就手动拆解查询，一步步 JOIN，看哪一步开始性能急剧下降。

-- 第1步：很快

SELECT c.id FROM categories c WHERE c.name = '手机';

-- 第2步：加一个JOIN，看看性能

SELECT p.id FROM products p JOIN categories c ON p.category_id = c.id WHERE c.name = '手机';

-- 第3步：再加一个...

...这种方法虽然笨，但极其有效，能精准定位到是哪个 JOIN 出了问题。

Part 5: 大表性能专题 - 当数据量过千万#5.1. 深分页问题的根治：从 LIMIT offset 到 “标签记录法” 和 “延迟关联”#现象：LIMIT 0, 10 也就是几毫秒，等到 LIMIT 1000000, 10 就像死机了一样。

原因：MySQL 并不是跳过前100万行，而是硬生生读取 1000010 行，然后把前100万行扔掉！这就叫“回表”回傻了。

解法1：标签记录法（推荐配合自增ID）

记住上次查到哪了（比如 id=1000000），下次直接从这开始：

-- ❌ 慢到怀疑人生

SELECT * FROM orders LIMIT 1000000, 10;

-- ✅ 飞一样的感觉 (前提是ID连续且要利用索引)

SELECT * FROM orders WHERE id > 1000000 LIMIT 10;解法2：延迟关联法（通用大招）

先在索引树上把 ID 找出来（不回表，只读索引快得很），然后再去拿完整数据。

SELECT t1.*

FROM orders t1

INNER JOIN (

-- 这里只查id，完全走索引，飞快

SELECT id FROM orders ORDER BY create_time LIMIT 1000000, 10

) t2 ON t1.id = t2.id;5.2. UPDATE 大表没索引：从行锁到表锁的灾难#MySQL (InnoDB)：行锁是加在索引上的！

如果你 UPDATE users SET age=10 WHERE name='zhangsan'，而 name 没索引：

恭喜你，表锁了！ 别人啥都干不了，只能等你更新完。

PostgreSQL: 同样需要注意锁升级和并发问题，但 PG 的 MVCC 机制在某些读写并发场景下表现更好。

5.3. 批量 INSERT 的正确姿势#不要一条条 INSERT！

不要一条条 INSERT！

合并写：INSERT INTO t VALUES (1, 'a'), (2, 'b'), (3, 'c')...;事务包裹：每条插入都开启提交事务是很慢的，手动开启事务，插完1000条一次提交。主键顺序：按主键顺序插入，减少页分裂。临时关闭索引：导入大量数据时，先删索引，导完再建（适合空表重建）。5.4. 架构级优化：分区表 (Partitioning) 在MySQL和PostgreSQL中的应用对比#当单表数据量达到数千万甚至上亿时，即使有索引，性能下降也难以避免。分区表就是一种在物理层面将大表“切”成多个小块的技术。

核心思想：查询时，如果带上分区键（通常是日期或某个范围ID），数据库可以直接定位到特定的小分区去查找，而忽略其他无关的分区。

MySQL (以日期范围分区为例):

CREATE TABLE orders (

id INT NOT NULL,

order_date DATE NOT NULL,

...

)

PARTITION BY RANGE (YEAR(order_date)) (

PARTITION p2022 VALUES LESS THAN (2023),

PARTITION p2023 VALUES LESS THAN (2024),

PARTITION p2024 VALUES LESS THAN (2025),

PARTITION p_future VALUES LESS THAN MAXVALUE

);

-- 查询时，MySQL会自动选择 p2024 分区，效率极高

SELECT * FROM orders WHERE order_date >= '2024-01-01' AND order_date < '2025-01-01';PostgreSQL (使用继承和触发器，或PG10+的声明式分区):

PG 10以后的声明式分区语法更简洁：

-- 创建主表（模板）

CREATE TABLE orders (

id INT NOT NULL,

order_date DATE NOT NULL

) PARTITION BY RANGE (order_date);

-- 创建具体的分区表

CREATE TABLE orders_2023 PARTITION OF orders

FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

CREATE TABLE orders_2024 PARTITION OF orders

FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');PostgreSQL 优势: PG 的分区表功能通常被认为比 MySQL 更成熟、更灵活。例如，PG 支持更复杂的分区策略，并且在分区管理上（如添加/删除分区）的操作对主表的锁定影响更小。

Part 6: 数据库架构与设计智慧#6.1. VARCHAR(50) vs VARCHAR(255): 不只是长度，更是内存#硬盘存储：没区别。存 “abc” 都是占 3 个字节 + 长度标识。

内存消耗：有区别！

MySQL 在读取数据进内存排序时，是按定义长度分配内存的。如果你定义 Varchar(255) 但只存 2 个字，排序时它可能还是会按 255 的长度预估内存。内存不够就会用磁盘排序（filesort），那就慢了。

结论：够用就行，别贪大。

6.2. 何时该上缓存 (Redis)?#当你的应用出现大量重复的读请求，并且数据不要求绝对的实时性时，就应该考虑上缓存了。

典型场景：

高频读取的配置信息：网站分类、地区列表等。热点数据：爆款商品的详情页、热门新闻文章。计算成本高的结果：复杂的统计报表、排行榜。缓存策略：

Cache-Aside (旁路缓存)：最常用。读的时候先读缓存，没有再读数据库，然后写回缓存。写的时候，先更新数据库，然后删除缓存（而不是更新缓存，这可以避免很多并发问题）。Read-Through/Write-Through：由缓存服务自身来保证与数据库的同步，应用层代码更简单。原则：缓存是用来挡流量的，不是用来存数据的。不要把所有东西都往缓存里塞。

6.3. 读写分离：基础架构的第一步#当单台数据库的写入压力（INSERT/UPDATE/DELETE）导致读取（SELECT）也变慢时，就该考虑读写分离了。

架构：

一个主库 (Master)：负责所有写操作。一个或多个从库 (Slave/Replica)：通过主从复制同步主库的数据，负责所有读操作。优点：

负载均衡：将读请求分散到多个从库，大大降低主库压力。高可用：主库挂了，可以手动或自动将一个从库提升为新的主库。注意：主从复制有延迟！对于要求强一致性的读操作（比如刚支付完就立刻看订单状态），需要强制从主库读取。

6.4. 冷热数据分离：成本与性能的双赢#一个表里既有上周的活跃数据，也有三年前的“僵尸数据”，查询性能肯定好不了。

策略：

创建历史表：例如，将 orders 表里一年之前的数据，定期迁移到 orders_history 表。定期归档：通过定时任务（如 cron + pt-archiver 工具）自动执行迁移。应用层改造：需要查询历史数据的后台功能，就去查历史表。大部分面向用户的查询只查主表。这样做的好处是让核心业务表保持“小而美”，查询性能得到保障，同时历史数据也没丢，只是换了个地方存，存储成本也可能更低（比如可以用压缩率更高的存储引擎）。

Part 7: 科学“跑分” - 如何正确地衡量优化效果#EXPLAIN 只是估算，不是实测。想知道你的优化到底有没有用，快了多少，必须进行科学的性能测试。

7.1. MySQL: profiling 的妙用#你可以让 MySQL 记录下执行一条 SQL 的详细时间开销。

-- 1. 开启 profiling

SET profiling = 1;

-- 2. 执行你的慢查询

SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE signup_date > '2023-01-01');

-- 3. 查看报告

SHOW PROFILES;

-- 找到你的查询ID，比如是1

-- 4. 查看详细开销

SHOW PROFILE FOR QUERY 1;这份报告会列出查询生命周期中每一步的耗时，比如 starting, checking permissions, Opening tables, Executing, Sending data 等。如果 Executing 耗时特别长，那基本就是查询本身的问题。

7.2. PostgreSQL: EXPLAIN ANALYZE 大杀器#PostgreSQL 在这方面做得更直接，EXPLAIN ANALYZE 会真实地执行查询，并返回详细的执行计划和实际耗时。

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'user_500@example.com';你会得到类似这样的结果：

QUERY PLAN

-------------------------------------------------------------------------------------------------------------

Index Scan using idx_email on users (cost=0.29..8.30 rows=1 width=118) (actual time=0.033..0.034 rows=1 loops=1)

Index Cond: (email = 'user_500@example.com'::text)

Planning Time: 0.083 ms

Execution Time: 0.049 mscost=0.29..8.30: 这是 PG 估算的成本。actual time=0.033..0.034: 这才是真实的执行时间！Execution Time: 0.049 ms: 整个查询的实际执行耗时。EXPLAIN ANALYZE 是 PG 性能优化的第一神器，因为它结合了“计划”和“现实”，让你一眼就能看出估算与实际的差距，精准定位问题所在。

7.3. Benchmarking 基本法#多次执行取平均值：不要只跑一次就下结论，网络抖动、系统缓存都会影响结果。至少运行5次以上取平均值。清空缓存（如果需要）：数据库有自己的查询缓存 (Query Cache)，为了模拟冷启动场景，你可能需要在两次测试之间重启数据库或执行特定命令来清空缓存。控制变量：每次只改一个地方（比如只加一个索引），然后测试，看效果。不要一次改一堆，最后都不知道是谁的功劳。Part 8: 实战演练场#8.1. 下载测试数据 (MySQL & PostgreSQL)#光看不练假把式。我为大家准备了生成测试数据的 SQL 脚本，直接执行就能生成 1000~10万 条数据，随便折腾！

数据概览：

users: 1000+ 用户products: 500+ 商品orders: 5000+ 订单 (带外键引用)📥 脚本下载：

🐘 MySQL 测试数据脚本🐘 PostgreSQL 测试数据脚本8.2. 动手实践：跟着文章的案例复现问题与优化#实操建议：

下载并导入脚本。随便写个 SELECT * WHERE phone = 123。敲个 EXPLAIN 看看是不是 ALL。加个索引，再 EXPLAIN，看看变成了 ref 没。使用 EXPLAIN ANALYZE (PG) 或 profiling (MySQL) 比较优化前后的真实时间！Part 9: 总结一下#SQL 优化是一场永无止境的修行，从单条查询的精雕细琢，到整个系统架构的深思熟虑，贯穿了软件开发的整个生命周期。

我们今天聊的核心可以浓缩为几个关键点：

诊断先行：EXPLAIN 是你的第一大神器，学会解读它，就等于拿到了数据库的“X光片”。先诊断，再开方。索引是核心武器：但武器不是万能的。必须警惕类型转换、函数包裹、最左前缀失效等七大“索引杀手”，确保你的索引能真正上场杀敌。理解执行原理：无论是 JOIN 的驱动顺序，还是 ORDER BY 的 filesort，理解数据库在背后为你做了什么，才能写出它“喜欢”的SQL。架构决定上限：当数据量达到一定级别，单点优化终将触及天花板。读写分离、缓存、分区表、冷热分离等架构策略，才是解决规模化问题的终极答案。希望这趟从理论到实战的旅程，能让你对SQL优化有一个全新的、更深入的认识。别忘了下载我们提供的测试数据，亲手实践一把。

祝大家代码无 Bug，查询 0 慢 SQL！🚀

参考：

SQL优化13连问，收藏好！