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