mysql 8.0 中无法通过存储过程“固定”执行计划，因 optimizer_switch 是会话级变量且影响全局，真正可靠方式是使用 optimizer hints（如 /+ use_index(...) /），它嵌入 sql、语句级生效、不污染会话。
MySQL 8.0 中无法通过存储过程“固定”执行计划——optimizer_switch 设置是会话级或全局级的，且对整个语句生效，不是按存储过程封装隔离的；真正能稳定执行计划的机制是 OPTIMIZER HINTS（优化器提示），它直接嵌入 SQL 语句中，优先级高于优化器自动决策。
为什么 SET optimizer_switch 在存储过程中不起固定作用
你看到的“在存储过程中开关 derived_merge”这类做法，本质是临时影响优化器行为，但存在几个硬伤：
-
optimizer_switch是会话变量，一旦被修改，会影响该会话后续所有查询，不只是当前存储过程里的那条SELECT - 它不保证计划唯一性：比如关掉
derived_merge只防派生表合并，但index_merge、range_optimizer_max_mem_size等其他开关仍可能让计划漂移 - MySQL 8.0+ 的优化器更激进，很多旧开关（如
semijoin）默认已启用，手动关反而可能引发非预期回退 - 存储过程本身不改变 SQL 文本结构，
EXPLAIN显示的 plan 仍是原始语句的，和你在客户端直接跑一模一样
用 OPTIMIZER HINTS 直接控制单条语句的执行路径
这才是 MySQL 8.0 推荐的、精准可控的执行计划“固定”方式。Hints 写在 SQL 里，只作用于当前语句，不污染会话状态。
常见实用 hints 示例：
- 强制走某个索引：
SELECT /*+ USE_INDEX(employees idx_dept_id) */ * FROM employees WHERE department_id = 3; - 禁止某类访问类型：
SELECT /*+ NO_RANGE_OPTIMIZATION(employees) */ * FROM employees WHERE salary > 5000; - 指定连接顺序（多表 JOIN）：
SELECT /*+ JOIN_ORDER(t1, t2, t3) */ ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...; - 禁用索引合并：
SELECT /*+ NO_INDEX_MERGE(orders) */ * FROM orders WHERE user_id = 1 OR status = 2;
注意：/*+ ... */ 是 MySQL 特有语法，必须紧贴 SELECT（或 UPDATE/DELETE）关键字后，中间不能换行或加空格。
在存储过程中安全使用 Hints 的写法
把 hint 当作文本拼进 SQL 字符串即可，无需额外配置。例如：
DELIMITER //
CREATE PROCEDURE GetEmployeesByDepartment(IN dept_id INT)
BEGIN
SELECT /*+ USE_INDEX(employees idx_department_id) */
employee_id, name, hire_date
FROM employees
WHERE department_id = dept_id;
END //
DELIMITER ;
这样每次调用该存储过程，都会强制走 idx_department_id 索引，哪怕优化器原本想选全表扫描或别的索引。
关键提醒：
- 确保 hint 中写的索引名真实存在，否则 MySQL 会静默忽略该 hint（不会报错）
- hint 不解决底层问题：如果
idx_department_id选择性极差（比如只有 2 个 distinct 值），强制走它反而更慢 - hint 会绕过统计信息更新的影响，所以当数据分布剧变时，你要人工判断是否需要调整 hint
验证 Hint 是否生效的最简方法
别依赖存储过程调用后的结果，直接对语句本身跑 EXPLAIN FORMAT=TREE 或 EXPLAIN ANALYZE：
-
EXPLAIN FORMAT=TREE SELECT /*+ USE_INDEX(employees idx_dept_id) */ ...—— 看输出里有没有-> Index lookup和对应索引名 -
EXPLAIN ANALYZE SELECT /*+ ... */ ...—— 实际执行并返回真实耗时、读取行数，比纯EXPLAIN更可靠 - 对比加 hint 前后
EXPLAIN的key和type字段是否变化
真正容易被忽略的是：hint 生效的前提是语句文本没被预处理改写。如果你在存储过程中用 PREPARE/EXECUTE 动态拼 SQL，hint 必须在拼接字符串里完整写出，不能靠变量注入——MySQL 不解析变量内容里的 hint。
