存储过程不适合封装ADD COLUMN操作，因其无法规避锁表、版本兼容或INSTANT条件校验，强行封装会掩盖风险；真正可落地的自动化需分层控制，由外部脚本驱动判断与执行，存储过程仅承担日志记录等轻量任务。
不能直接用存储过程“自动”完成安全的在线加字段操作——因为 ALTER TABLE 本身不支持在存储过程中动态规避锁表、版本兼容或 INSTANT 条件校验，强行封装反而掩盖风险。
为什么存储过程不适合封装 ADD COLUMN 操作
MySQL 存储过程执行的是预编译 SQL，但它无法替代 DDL 的语义约束和运行时环境判断。常见误用场景包括：
- 把
ALTER TABLE ... ADD COLUMN包进循环或条件分支，却没检查表是否满足ALGORITHM=INSTANT条件，结果静默降级为INPLACE，锁表几分钟才报错 - 用拼接字符串构造 SQL（如
CONCAT('ALTER TABLE ', tbl, ' ADD COLUMN ...')），但PREPARE/EXECUTE不支持ALGORITHM提示，导致 INSTANT 被忽略 - 试图在存储过程中自动检测行格式、全文索引、压缩状态等，代码冗长且易漏判（比如漏查
information_schema.INNODB_TABLES中的ROW_FORMAT）
真正可落地的“自动化”做法是分层控制
把“判断”和“执行”拆开，由外部脚本或运维平台驱动，存储过程只承担轻量、确定性高的辅助任务：
- 用 Python/Shell 先查
SELECT VERSION(), ENGINE, ROW_FORMAT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'，再查是否有全文索引：SELECT COUNT(*) FROM information_schema.STATISTICS WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t' AND INDEX_TYPE='FULLTEXT' - 确认通过后，再调用带显式
ALGORITHM=INSTANT的语句（不是存在存储过程里，而是由调用方拼好执行） - 存储过程仅用于后续动作，例如：记录加字段日志到审计表、触发下游配置刷新、或批量更新旧数据（
UPDATE ... LIMIT分片逻辑）
ALGORITHM=INSTANT 必须显式写出，不能依赖默认行为
即使 MySQL 8.0.29+ 支持 AFTER 定位加列，也不代表它会自动选 INSTANT。不写 ALGORITHM=INSTANT 就等于放弃主动控制权：
- 不满足条件时，MySQL 默认 fallback 到
INPLACE，你看到Query OK就以为成功了，实际耗时 12 分钟、主从延迟飙升 - 写了
ALGORITHM=INSTANT后失败，错误明确：ERROR 1845 (0A000): ALGORITHM=INSTANT is not supported for this operation，立刻知道要查哪条限制被违反 - 注意：8.0.12–8.0.28 不支持
AFTER+INSTANT，哪怕语句写对也会退化；8.0.29+ 才真正放开，必须先SELECT VERSION()确认
行版本超限（64）是容易被忽略的硬限制
每次 ADD COLUMN 或 DROP COLUMN 都会增加一个行版本，上限固定为 64（MySQL 9.1 才升到 255）。这个计数器藏在 InnoDB 内部，不暴露在常规视图里：
- 超限后报错：
ERROR 4092 (HY000): Maximum row versions reached for table db.t，此时任何加减列操作都拒绝，只能重建表 - 重建是唯一解法：
CREATE TABLE t_new LIKE t; ALTER TABLE t_new ADD COLUMN ...; INSERT INTO t_new SELECT *, NULL FROM t; RENAME TABLE t TO t_bak, t_new TO t; - 没有存储过程能绕过这个限制——它是物理层面的结构约束，不是权限或语法问题
