MySQL默认倾向Nested-Loop Join，表数增加会导致嵌套扫描次数爆炸式增长，驱动表选错、索引失效、中间结果膨胀及连接池耗尽均会引发性能雪崩。
执行计划里嵌套循环次数爆炸式增长
JOIN 表数每增加一个，优化器在 Nested-Loop Join 场景下可能触发新一轮内层扫描。比如 3 张表 t1 JOIN t2 ON t1.id = t2.t1_id JOIN t3 ON t2.id = t3.t2_id，若驱动表 t1 有 1 万行、t2 平均匹配 5 行、t3 每次再匹配 3 行，理论扫描行数就达 10000 × 5 × 3 = 15 万；到 5 张表时，哪怕每层只匹配 2 行，也变成 10000 × 2⁴ = 160 万——这还没算索引失效导致的全表扫。
关键点：
- MySQL 默认倾向 Nested-Loop，尤其当关联字段无索引或统计信息陈旧时
-
EXPLAIN中type列出现ALL或index（非覆盖索引）是危险信号 - 驱动表选错会直接放大嵌套深度：大表在
FROM后第一个JOIN位置且无WHERE过滤，极易被当作驱动表
JOIN顺序失控导致临时表膨胀
优化器对 ≥4 张表的 JOIN 常无法准确估算中间结果集大小，尤其当某张维度表数据分布倾斜（如 status=1 占 95%），它可能错误选择该表为驱动表，生成百万级中间结果写入磁盘临时表（Using temporary; Using filesort 出现在 Extra 列）。
真实影响：
- 临时表默认走内存（
tmp_table_size），超限后落盘，I/O 成瓶颈 - JOIN 字段含大量
NULL时，优化器认为选择性差，主动弃用索引，加剧临时表体积 - 显式用
STRAIGHT_JOIN可强制顺序，但必须配合EXPLAIN FORMAT=TREE验证是否真减少rows
索引失效链：类型不匹配 → 隐式转换 → 全表扫描
两个表 ON 字段类型不一致（如 orders.order_no VARCHAR(32) 和 log_records.order_id BIGINT），MySQL 必须把 BIGINT 转成字符串做比对，导致 order_id 上的索引完全失效。
检查项：
- 用
SHOW CREATE TABLE对比两边字段的DATA_TYPE、COLLATION、是否允许NULL -
EXPLAIN中key列为空、rows等于表总行数，基本可断定隐式转换发生 - 修复不是加
CONVERT(... USING ...)，而是统一源头字段类型——迁移脚本改列类型比运行时转换更治本
连接数耗尽引发雪崩的实际路径
单条多表 JOIN 查询执行 400ms，而应用连接池只有 50 个连接。当 QPS 达到 150，每秒有 60 个请求在排队等待连接，平均响应时间从 400ms 涨到 2.3s；上游服务超时重试，流量翻倍，连接池迅速打满，新请求全部卡在 Waiting for connection 状态。
这不是理论风险：
- MySQL 的
wait_timeout和应用层连接池的maxWait设置不匹配会放大排队效应 -
SHOW PROCESSLIST里大量State: Sending data或Copying to tmp table是典型征兆 - 别依赖“只是偶尔慢”，一旦某个 JOIN 因数据量增长跨过临界点（比如用户表从 100 万涨到 800 万），雪崩可能一夜之间发生
真正难处理的是那些“看起来还行”的 JOIN：执行时间 200ms、EXPLAIN 显示走了索引、监控没报慢 SQL——但它正悄悄吃掉连接池余量，等某天批量任务一起跑，就再也抢不到连接了。
