出现Nested Loop需警觉，说明关联未走索引驱动，可能因被驱动表缺索引、字段类型不一致或统计信息过期；应验证rows值、运行时间及单表执行计划，再通过添加索引、统一字段类型或更新统计信息优化。
Navicat里点“解释”按钮后看到Nested Loop就该警觉
只要执行计划中出现 Nested Loop（尤其在MySQL里显示为 type: ALL 或 type: index 配合 Extra: Using join buffer），基本说明关联逻辑没走索引驱动，正在做笛卡尔积式扫描。这不是语法错误，而是优化器被迫退化——通常因为被驱动表缺有效索引、连接字段类型不一致、或统计信息过期。
确认Nested Loop是否真成瓶颈的三个动作
别只看“有Nested Loop”就改SQL，先验证它是否实际拖慢了查询：
- 在Navicat中选中SQL，点击
解释按钮，切换到解释标签页，重点看rows列：如果某行的预估扫描行数是几万甚至几十万，而它又是被嵌套循环反复执行的（即出现在缩进更深的位置），那它就是热点 - 右键该SQL →
运行已选择的，看底部显示的运行时间；再手动加SQL_NO_CACHE（如SELECT SQL_NO_CACHE ...）重跑一次，排除查询缓存干扰 - 对比关联表的
EXPLAIN SELECT * FROM 表名结果：如果被驱动表本身type是ALL，说明连单表扫描都全表扫，Nested Loop只是把问题放大了
让Nested Loop变快的实操路径
目标不是消灭Nested Loop（它本身是合理算法），而是让它驱动得“轻”、被驱动得“准”：
- 检查连接条件字段是否都有索引：比如
ON a.id = b.a_id，a.id通常是主键（自带索引），但b.a_id必须单独建索引，否则每次循环都要全表扫b - 确认字段类型和字符集完全一致：
a.id是BIGINT，b.a_id却是VARCHAR(20)？这种隐式转换会让索引失效，执行计划里会标出type: ALL+Extra: Using where - 对被驱动表加
STRAIGHT_JOIN强制顺序（仅调试用）：把原本可能被优化器选作外层的“大表”固定为内层，看执行计划是否转成ref或eq_ref；若有效，说明优化器误判了表大小，需更新统计信息（ANALYZE TABLE 表名）
容易被忽略的MySQL特例：Index Nested-Loop vs Block Nested-Loop
MySQL 5.6+ 默认启用 BNL（Block Nested-Loop），它用join buffer缓存外层结果批量匹配，比传统NL快，但会吃内存。你可能在 Extra 里看到 Using join buffer (Block Nested Loop) —— 这不是坏信号，反而是优化过的痕迹。但要注意：join_buffer_size 默认才256KB，如果外层结果集大，buffer频繁刷写反而更慢。此时应调高该值（需在MySQL配置里设，Navicat里改不了）。
