MySQL 8.0中存储过程对不可变参数的处理有哪些优化？

MySQL 8.0 不支持 IN 参数不可变性约束，其“不可变”仅为约定；优化体现为按需引用+延迟拷贝以减少冗余复制，并在预编译阶段对仅含 IN 参数的确定性表达式做更激进的常量折叠。

MySQL 8.0 不支持存储过程中声明“不可变参数”（如 INOUT 或 OUT 参数的只读约束），也没有类似其他数据库（如 PostgreSQL 的 CONSTANT、Oracle 的 IN 默认不可赋值）那样的语法级保护机制。所谓“不可变参数”，在 MySQL 存储过程语境里，实际指的就是 IN 类型参数——它按设计本不应被修改，但 MySQL 不会阻止你在过程体内给 IN 参数重新赋值。

这带来一个关键事实：

MySQL 8.0 对 IN 参数的“不可变性”纯属约定，无运行时保障，也无编译期检查；所谓“优化”，不是加强约束，而是围绕这个松散语义做执行效率和行为可预测性的改进。

---

IN 参数被意外修改后，MySQL 8.0 不再隐式复制变量值

早期 MySQL 版本（如 5.7）在调用存储过程时，会对 IN 参数做浅拷贝，即使你没改它，也会占用额外栈空间；而 8.0 在多数场景下改为按需引用+延迟拷贝：

• 如果你全程没对 IN 参数赋值（即保持其原始值），MySQL 会直接复用传入值的内存地址或内部表示，避免冗余复制；
• 一旦你执行了类似 SET p_name = CONCAT(p_name, '_new');，才触发真正赋值逻辑（此时才分配新空间）；
• 这降低了轻量级存储过程的启动开销，尤其在高频调用、参数为大字符串或 JSON 时更明显。

注意：该行为对用户透明，无需配置，但依赖于参数未被重写这一前提。

---

IN 参数参与表达式计算时，常量折叠更激进

MySQL 8.0 的存储过程解析器在预编译阶段，会对仅含 IN 参数的确定性表达式做更多静态推导：

• 示例：

  CREATE PROCEDURE p_test(IN p_id INT)BEGIN  DECLARE v_flag BOOLEAN DEFAULT (p_id > 100 AND p_id < 200);  SELECT v_flag;END;

• 若调用 CALL p_test(150);，MySQL 8.0 可能在 prepare 阶段就将 v_flag 推导为 TRUE，跳过运行时布尔运算；
• 但若 p_id 来自变量或函数（如 SELECT @x），则不触发该优化。

这并非总是发生，取决于表达式是否满足“编译期可求值”条件（无外部依赖、无随机/时间函数、无用户变量）。

---

调试和监控中，IN 参数的值更稳定、不易被污染

MySQL 8.0 改进了存储过程执行上下文隔离：

• IN 参数的初始值在进入过程时被快照（snapshot），后续即使同名用户变量被修改（如 SET @p_id = 999;），也不会影响过程内 p_id 的值；
• Performance Schema 中的 events_statements_history 表记录调用时的原始 IN 值（而非过程内可能被覆盖后的值），方便回溯；
• 错误日志中打印的 ERROR 1366 (HY000) 等报错上下文，能更准确关联到传入的 IN 值，而不是过程中间态。

这点容易被忽略：很多线上问题看似是参数“被改了”，其实是开发者在过程里误用了同名用户变量，而 8.0 的隔离增强让这种混淆更少发生。

---

真正需要“不可变语义”的场景，目前只能靠编码规范+代码审查来保障。MySQL 8.0 没有提供 CONSTANT IN 或 READONLY 修饰符，也不校验 IN 参数是否被赋值——它只是让“守规矩”的写法跑得更快、更稳，而对“破规矩”的写法，既不阻止，也不优化。