INOUT参数必须用已声明的用户变量调用，不可传字面量；其值在过程中被就地修改，调用后立即生效，且不受事务回滚影响，需注意类型兼容性、变量初始化及命名冲突。
INOUT参数必须用用户变量调用，不能直接传字面量
MySQL会拒绝把常量（比如 10、'abc'）当作 INOUT 参数传入，报错类似 ERROR 1318: Incorrect number of arguments for PROCEDURE xxx; expected 1, got 1（看似矛盾，实为类型校验失败）。这是因为 INOUT 要求参数既能读又能写，而字面量不可赋值。
实操建议：
- 调用前必须用
SET @var = ...显式声明并初始化用户变量 - 变量类型要和存储过程中声明的类型兼容（如过程定义
INOUT age INT，就不能用@age := '25'字符串赋值） - 避免在同一个会话中复用同名变量而不重置，否则可能带入上一次的脏值
INOUT变量在过程内被修改后，原变量值立即改变
和函数返回值不同，INOUT 不是“返回新值”，而是就地修改调用者传入的变量。这意味着：如果过程里执行了 SET age := age * 2，调用结束后 @age 就已是翻倍后的结果，无需额外 SELECT 或 INTO。
常见错误现象：
- 误以为需要
SELECT age INTO @var才能拿到结果 —— 实际完全不需要，@var已更新 - 在循环或条件分支中多次修改同一
INOUT变量，但没意识到每次SET都直接生效，容易逻辑错乱 - 多个
INOUT参数间存在依赖时（如INOUT a INT, INOUT b INT），修改顺序会影响最终状态
混合使用IN/OUT/INOUT时，参数顺序和类型必须严格匹配
MySQL不支持按名称传参，只认位置。声明为 CREATE PROCEDURE p(IN x INT, INOUT y VARCHAR(20), OUT z DATE)，那么调用时 CALL p(@a, @b, @c) 中的 @a 必须是可读的整型变量，@b 必须是已声明的字符串变量，@c 也必须是已声明的日期变量（哪怕初始为 NULL）。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
容易踩的坑：
- 把
OUT参数当成INOUT传入一个未初始化的变量（如@out_var从未SET过），虽不报错，但过程内若用到该变量值（非仅INTO赋值），会因NULL参与运算导致意外结果 - 在存储过程体中对
INOUT参数做SELECT ... INTO，会覆盖之前所有修改 —— 因为INTO是赋值操作，不是追加 -
INOUT和同名列名冲突：参数名不能和过程体内任意表的字段名相同，否则WHERE col = param类语句可能解析歧义
事务中使用INOUT需注意变量生命周期不受事务回滚影响
INOUT 变量是会话级的用户变量，它的修改发生在服务器内存中，和事务的 ACID 无关。即使你在 START TRANSACTION 内调用含 INOUT 的存储过程，并随后执行 ROLLBACK，那个 @var 的值依然保留着过程执行后的结果。
这意味着：
- 不能靠事务回滚来“撤销”
INOUT的副作用 - 如果过程内有 DML 操作 +
INOUT状态更新，应确保两者语义一致；否则可能 DML 回滚了，但业务状态变量却已变更 - 测试时容易忽略这点：手动
ROLLBACK后以为一切还原，结果SELECT @var还是上次的值，造成调试困惑
复杂点在于：INOUT 看似简单，实则把变量作用域、事务边界、类型隐式转换三者耦合在一起——稍不留意，变量就变成了“幽灵状态”的携带者。
