优化存储过程多表关联需从执行计划和数据流入手：用EXPLAIN确认真实路径，避免参数绑定干扰；强制裁剪基数、控制驱动顺序、合理使用索引与条件位置。
存储过程里多表关联慢，不是语法写错了，而是中间结果集失控了——优化得回到执行计划和数据流本身动手。
用 EXPLAIN 确认真实执行路径，别信存储过程封装
存储过程中的参数绑定、变量类型、缓存计划都会让优化器选错路径。必须在过程内嵌入 EXPLAIN（MySQL）或 EXPLAIN ANALYZE（PostgreSQL），否则看到的只是“理想计划”。
- 重点看
type字段：出现ALL或index说明关联字段没走有效索引 - 检查
rows列：如果某张大表预估扫描行数接近全表（比如订单表100万行，rows显示98万），说明WHERE条件根本没下推 -
Extra中含Using temporary或Using filesort？大概率是JOIN后才做GROUP BY/ORDER BY，或者ON里用了函数
把过滤条件显式下推到子查询或 CTE，别等 JOIN 完再筛
存储过程常因复用逻辑写成“先 JOIN 再 WHERE”，但数据库不会自动把外层条件下推。例如：
SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 1 AND o.create_time >= @start_date;
这会让 orders 全量参与连接。正确做法是强制裁剪基数：
SELECT u.name, o.amount
FROM users u
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 可物化，老版本建议用派生表（即上面的子查询）
- 避免在
ON或WHERE中对字段用函数，比如DATE(o.create_time) = CURDATE()→ 改为o.create_time >= CURDATE() AND o.create_time < DATE_ADD(CURDATE(), INTERVAL 1 DAY) - 确保子查询返回字段类型与主表严格一致，否则隐式转换会废掉索引
小表驱动大表 + STRAIGHT_JOIN 控制顺序，别赌优化器猜对
MySQL 对存储过程内变量值预判不准，容易选错驱动表。比如 users 表10万行、orders 表500万行，本该用 users 驱动，但过程里先聚合了 orders，优化器可能反向驱动。
- 用
STRAIGHT_JOIN强制顺序：SELECT /*+ STRAIGHT_JOIN */ u.name, o.amount FROM users u STRAIGHT_JOIN orders o ON u.id = o.user_id - 若中间结果来自临时表，务必在
INSERT前建好索引：CREATE TEMPORARY TABLE tmp_orders (...); ALTER TABLE tmp_orders ADD INDEX idx_user_status (user_id, status); - 右表
ON字段必须有索引，且复合索引顺序要匹配ON条件顺序，比如ON b.a_id = a.id AND b.status = 'paid'，索引就得是(a_id, status)，不能反过来
LEFT JOIN 后加 WHERE 右表字段？它已经不是 LEFT JOIN 了
这是最隐蔽的性能陷阱：SELECT * FROM a LEFT JOIN b ON a.id = b.a_id WHERE b.status = 'done'，语义上是 LEFT，实际执行等价于 INNER JOIN——所有 b 为 NULL 的行都被干掉了。
- 想保留左表全部行，又只取右表满足条件的数据？把条件挪进
ON：LEFT JOIN b ON a.id = b.a_id AND b.status = 'done' - 如果后续还要取
b的字段（如b.qty），就不能只靠EXISTS；但若只判断存在性，EXISTS比LEFT JOIN ... IS NOT NULL快得多，且不生成中间行 - 预聚合时记得补
COALESCE：COALESCE(os.total_spent, 0)，否则NULL会透传导致 JOIN 后丢失左表行
真正难的不是写对 SQL，而是在存储过程上下文里让每一步都可控：变量类型、临时表索引、驱动顺序、条件位置——漏掉任何一个，前面优化全白费。
