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 参数是否被赋值——它只是让“守规矩”的写法跑得更快、更稳，而对“破规矩”的写法，既不阻止，也不优化。
