mysql 8.0.16+ 支持 rename procedure 原子切换，可避免调用中断：先导出原逻辑并新建同名新过程（如 p_order_stats_v2），再执行 rename procedure p_order_stats to p_order_stats_bak, p_order_stats_v2 to p_order_stats，最后验证结果一致性。
直接 DROP + CREATE 会中断正在调用的老业务，尤其当应用层没做重试或兜底时，容易触发空结果或报错。必须用原子性替换方案。
MySQL 8.0 中如何安全替换旧存储过程（不中断调用）
MySQL 8.0.16+ 支持 RENAME PROCEDURE，这是唯一能避免调用中断的原子操作。它不修改权限、不重置执行统计、不触发 sys.dm_exec_procedure_stats 清零。
- 先导出原逻辑：
SHOW CREATE PROCEDURE p_order_stats，确认参数签名（比如是否有OUT参数、是否依赖临时表） - 新建同名新逻辑的过程，但用不同名字，例如
p_order_stats_v2，完整实现并测试通过 - 执行原子切换：
RENAME PROCEDURE p_order_stats TO p_order_stats_bak, p_order_stats_v2 TO p_order_stats - 切换后立刻验证：
CALL p_order_stats('2025-01-01', '2025-01-31')，比对结果与历史一致
注意：不要用 ALTER PROCEDURE 替代——它仅支持修改特性（如 SQL SECURITY、COMMENT），不能改函数体；也不要依赖 DROP PROCEDURE IF EXISTS + CREATE，这会造成毫秒级不可用窗口，足够让上游服务报错。
WHERE 条件写法导致索引失效的典型坑
老过程常写 WHERE DATE(pay_time) = '2025-01-01'，这会让 pay_time 索引完全失效，执行计划出现 type: ALL 和高 rows 值。
- 错误写法：
DATE(pay_time) BETWEEN in_start_date AND in_end_date→ 无法走索引 - 正确写法：
pay_time >= in_start_date AND pay_time - 配套检查索引：
SHOW INDEX FROM order_main WHERE Key_name = 'idx_pay_time_status'，确保包含pay_time和高频过滤字段（如pay_status） - 若缺失复合索引，先建：
CREATE INDEX idx_pay_time_status ON order_main(pay_time, pay_status)
别只看 EXPLAIN 是否用了索引，要盯住 key_len 和 rows：如果 key_len 明显小于预期（比如只用了 pay_time 的前 4 字节），说明索引没全利用。
NULL 参数传入时的逻辑陷阱
IN 参数传 NULL 是高频故障点。比如店铺 ID 为空本意是“不限店铺”，但 WHERE shop_id = NULL 永远为 false（三值逻辑）。
- 危险写法：
shop_id = IFNULL(in_shop_id, shop_id)→ 多数 MySQL 版本下无法利用索引 - 推荐写法：
AND (in_shop_id IS NULL OR shop_id = in_shop_id)，注意括号不能省，否则AND优先级高于OR，逻辑全乱 - 若字段本身允许
NULL，且业务上shop_id = 0表示“无归属”，建议统一用0代替NULL传参，规避三值逻辑干扰
这个分支判断在 EXPLAIN 中仍显示 type: ref，只要 shop_id 有索引，就能走索引查找，只是多一次 IS NULL 判断开销。
重构后性能反而下降？重点查这三处
看似逻辑等价，但执行计划可能完全不同。不要只比对结果，要盯住 EXPLAIN FORMAT=TRADITIONAL 输出。
- 查是否用了
Using temporary或Using filesort：说明GROUP BY没走索引，需补ORDER BY NULL或调整分组字段顺序 - 查
rows是否暴涨：比如从 1000 跳到 500000，大概率是某个条件写法导致索引失效 - 查
filtered值是否极低（如 ANALYZE TABLE order_main 更新
最易被忽略的是：新过程里加了 ORDER BY 却没对应索引，或者把原来单字段 GROUP BY 改成多字段，却没建覆盖索引——这些改动不会报错，但会在高并发下暴露性能断崖。
