大表关联查询变慢主因是执行计划失控，表现为驱动表选错、中间结果膨胀、索引失效；需在存储过程内用explain analyze等查真实执行计划，紧盯starts与a-rows差异，并显式裁剪数据集、避免字段函数操作。
大表关联查询在存储过程中变慢，根本不是“写在存储过程里”导致的，而是底层SQL执行计划失控——驱动表选错、中间结果膨胀、索引静默失效这三类问题占了九成以上。
为什么EXPLAIN在存储过程里不靠谱？
直接在客户端执行 EXPLAIN SELECT ... 看到的计划，和存储过程实际跑出来的往往不一致。因为存储过程用绑定变量、参数化执行、计划缓存复用，优化器可能固化一个低效计划并反复使用。
- 必须在存储过程内部嵌入真实执行语句 +
EXPLAIN ANALYZE（PostgreSQL）或SET STATISTICS XML ON（SQL Server），或者查V$SQL_PLAN（Oracle）中对应sql_id的最后一次执行记录 - 重点盯紧
STARTS和A-Rows：如果某张表STARTS=100000但业务上只该查 100 行，说明驱动顺序彻底反了 -
type=ALL或Extra=Using temporary; Using filesort是硬指标，意味着关联前没过滤、ORDER BY 没走索引、或 JOIN 后才加 WHERE
怎么让大表不参与全量JOIN？
别信“先 JOIN 再 WHERE”，数据库不会自动把外层条件下推到子表。尤其当参数是 @start_date 这类动态值时，必须显式裁剪数据集。
- 用派生表强制提前过滤：
JOIN (SELECT user_id, amount FROM orders WHERE status = 1 AND create_time >= @start_date) o ON u.id = o.user_id - MySQL 8.0+ 可用 CTE，但老版本务必用括号子查询——CTE 在 5.7 及以前只是语法糖，不物化
- 避免在
ON或WHERE中对字段用函数：DATE(o.create_time) = CURDATE()会让索引失效；改用o.create_time >= CURDATE() AND o.create_time - 检查字段类型是否严格一致：比如
orders.user_id是BIGINT，但存储过程参数@uid定义为INT→ 触发隐式转换 → 索引失效
LEFT JOIN + WHERE 判断存在性？立刻换 EXISTS
只要目标只是“主表某条记录在从表是否存在”，就别用 LEFT JOIN ... WHERE b.id IS NOT NULL。它会先生成全部 LEFT JOIN 结果（可能百万行），再过滤，中间结果完全失控。
- 差写法：
SELECT o.* FROM orders o LEFT JOIN order_items i ON o.order_id = i.order_id WHERE i.order_id IS NOT NULL - 好写法：
SELECT o.* FROM orders o WHERE EXISTS (SELECT 1 FROM order_items i WHERE i.order_id = o.order_id) - 注意：如果还要取
i.product_name等字段，就得回到 JOIN，但此时必须确保order_items(order_id)有索引，且不能含 NULL 值干扰连接逻辑
聚合类查询为什么越 JOIN 越慢？
要查“每个客户的总金额+最近下单时间”，直接 JOIN orders + JOIN order_items + GROUP BY 会把所有明细行加载进内存。而客户数可能只有几千，订单明细却有千万级。
- 低效方式：所有明细一次性拉出，GROUP BY 在巨量数据上做
- 优化方式：先各自聚合，再用主键关联。例如用 CTE 或临时表先算出
cust_id → total_amt, last_order，再和customers表 JOIN - 额外收益：聚合后的中间结果体积常压到原数据的千分之一以下，网络传输、内存占用、CPU 计算全降维打击
最容易被忽略的点是：存储过程里变量类型和表字段不匹配，会导致索引静默失效——没有报错、没有警告，但执行计划里 type 突然变成 ALL，rows 爆涨十倍。每次改参数类型，都得重新验证执行计划。
