MySQL不支持原生版本化迁移，存储过程仅可作为手动单步迁移执行器；需自行管理版本号、顺序和幂等性，并配合schema_migrations表追踪执行状态。
MySQL 本身不提供像 Flyway 或 Liquibase 那样的原生版本化迁移能力，存储过程不能直接替代迁移框架，但可以作为轻量级、可控的“手动版迁移引擎”来使用——前提是你要自己管理版本号、执行顺序和幂等性。
为什么不用存储过程做全自动版本迁移
MySQL 的 information_schema.ROUTINES 不记录创建时间戳或版本元数据；CREATE PROCEDURE 无法覆盖已存在同名过程（除非显式 DROP）；且存储过程不具备跨会话状态、无法自动发现待执行脚本。这意味着：它不适合当“迁移调度器”，只适合当“单步迁移执行器”。
用存储过程封装单次迁移逻辑（推荐做法）
把每个迁移步骤（如新增字段、重命名表、修正脏数据）写成独立的、带版本标识的存储过程，由外部逻辑（Shell/Python/CI）按序调用。例如：
DELIMITER $$
CREATE PROCEDURE migrate_v20240601_add_status_column()
BEGIN
IF NOT EXISTS (
SELECT 1 FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'mydb'
AND TABLE_NAME = 'orders'
AND COLUMN_NAME = 'status'
) THEN
ALTER TABLE orders ADD COLUMN status TINYINT DEFAULT 0;
END IF;
END$$
DELIMITER ;
- 过程名含日期或语义版本（如
migrate_v20240601_...），便于识别顺序 - 每一步都做存在性检查（如字段是否存在、索引是否已建），保证幂等
- 避免在过程内写
COMMIT或START TRANSACTION—— 交给调用方控制事务边界 - 不要依赖
DELIMITER在导入时出错：导出 SQL 文件必须保留DELIMITER $$和结尾分号
如何追踪已执行的迁移版本
靠一张简单表记录，而不是靠存储过程是否存在：
CREATE TABLE schema_migrations ( version VARCHAR(32) PRIMARY KEY, applied_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
调用迁移前先查表，未存在才执行对应过程并插入记录：
INSERT IGNORE INTO schema_migrations (version) VALUES ('v20240601_add_status_column');
-
INSERT IGNORE或ON DUPLICATE KEY UPDATE防止重复执行 - 别用
SELECT COUNT(*)+IF判断再插入——并发下有竞态风险 - 这张表必须在所有迁移过程之前就存在，且初始为空或含 baseline 版本
容易被忽略的执行细节
真正卡住人的不是语法，而是环境一致性：
- 目标库字符集与排序规则（
COLLATION）必须和源库一致，否则ALTER TABLE ... CONVERT TO类操作可能静默失败 - 存储过程里用到的函数（如
JSON_EXTRACT）需确认 MySQL 版本支持——5.7.8+ 才有完整 JSON 支持 - 大表
ALTER操作放在过程里会阻塞整个调用，建议拆成两步：先建新表+同步数据，再原子切换（RENAME TABLE） - 权限问题常被忽视：
EXECUTE权限要授予调用者，且过程内涉及的表操作需有对应ALTER/INSERT权限
归根结底，存储过程只是执行容器，版本管理、依赖校验、回滚逻辑、日志记录这些事，得靠外部脚本或流程兜底。把它当成“可复用的 SQL 封装块”，比当成“迁移框架”更现实。
