最常被忽略的性能雷区是Nested Loop驱动大表，即百万级表出现在内层被逐行扫描，常见于缺失索引、函数包裹ON条件或OR拆分连接；需检查Rows Removed by Filter、logical_reads超10万页、type: ALL非驱动表、JOIN超5个跨域关联、统计信息陈旧致驱动顺序错误、非等值连接、三层嵌套聚合内存爆满、函数/CAST使索引失效等。
看执行计划里有没有 Nested Loop 驱动大表
这是最常被忽略的性能雷区。当 EXPLAIN（或 EXPLAIN ANALYZE）显示某张行数上百万的表出现在 Nested Loop 的内层（即被外层结果集逐行驱动），哪怕只查 10 行，实际也可能扫描千万级记录。
常见诱因包括：缺失连接字段索引、ON 条件写成函数包裹（如 ON UPPER(a.name) = UPPER(b.name)）、用 OR 拆分连接条件导致优化器放弃哈希/合并连接。
- 检查
EXPLAIN输出中Rows Removed by Filter是否远高于Actual Rows—— 这说明大量中间结果被丢弃，过滤逻辑没下推 - 用
pg_stat_statements（PostgreSQL）或sys.dm_exec_query_stats（SQL Server）查历史平均logical_reads，单次查询超 10 万页读基本算过复杂 - MySQL 用户注意：
type: ALL出现在EXPLAIN的非驱动表上，基本等于“正在全表扫”
JOIN 数量超过 5 个且无明确业务边界
不是语法报错，但意味着查询责任模糊、变更风险高、缓存失效快。尤其当多个 JOIN 涉及不同业务域（比如同时连订单、库存、物流、用户画像、营销活动），任何一端数据模型微调都可能让整个查询崩掉或返回错误聚合结果。
更隐蔽的问题是：优化器在多表关联时容易选错驱动顺序，尤其当统计信息陈旧（ANALYZE 没跑过）或存在 LEFT JOIN + WHERE 字段来自右表时，会隐式转成 INNER JOIN，结果集意外缩水。
- 把跨域关联拆成应用层多次查询，用主键集合做二次匹配（例如先查订单 ID 列表，再用
IN (…)查对应用户标签） - 确认每个
JOIN是否真需要：用EXISTS替代LEFT JOIN … WHERE xxx IS NULL常能砍掉一个表 - 避免在
ON子句里混用=和!=或范围条件（如a.id > b.ref_id），这类非等值连接几乎必然触发嵌套循环
子查询嵌套深度 ≥ 3 层且含聚合或窗口函数
三层嵌套本身不致命，但若最内层有 COUNT(*) OVER (PARTITION BY x)，中间层又用 GROUP BY，外层再套 ORDER BY … LIMIT，数据库就得把中间结果全算出来才能裁剪——内存爆掉、临时磁盘写满都是常态。
典型症状是 EXPLAIN 显示 Materialize 节点出现在关键路径上，且估算行数和实际行数偏差超 10 倍（说明统计信息严重失真，优化器误判）。
- 把最内层聚合结果物化成临时表（
CREATE TEMP TABLE AS SELECT …），显式控制生命周期 - 用 CTE（
WITH）替代子查询时，注意 PostgreSQL 会强制物化，而 MySQL 8.0+ 默认不物化——别假设行为一致 - 窗口函数尽量靠近最终输出层，避免在子查询里提前计算再被外层过滤掉（如
ROW_NUMBER()算了 100 万行，最后只取第 1 行）
WHERE 条件里出现 CAST、函数或表达式作用于索引字段
比如 WHERE DATE(created_at) = '2024-01-01' 或 WHERE SUBSTR(phone, 1, 3) = '138'，会导致索引完全失效。优化器只能全表扫描，而你可能根本没意识到——因为 EXPLAIN 只说 Seq Scan，不告诉你“本可以走索引但被你写废了”。
更麻烦的是隐式转换：字符串字段存数字（status VARCHAR(10)），却写成 WHERE status = 1，MySQL 会把整列转为数字比对；SQL Server 在某些兼容模式下也会干类似的事。
- 索引字段必须裸写：改成
WHERE created_at >= '2024-01-01' AND created_at - 字符串字段查数字？统一转成字符串比较：
WHERE status = '1'，并确保字段类型和值类型严格一致 - 用
pg_indexes（PostgreSQL）或sp_helpindex（SQL Server）确认索引是否真被创建在目标列上，别信名字——idx_user_created可能建在updated_at上
真正难判断的，从来不是“语法有多长”，而是“哪一行改动会让响应时间从 200ms 暴涨到 12s”。盯住执行计划里的实际扫描行数、物化节点位置、索引使用状态，比数 JOIN 个数有用得多。
