MySQL存储过程需通过存在性判断和条件分支实现可重复执行：8.0.13+用DROP PROCEDURE IF EXISTS，5.7及以前需查mysql.proc；结构变更须查information_schema；DDL须动态拼接并PREPARE执行；ALTER TABLE不可回滚。
MySQL 存储过程本身不能直接“保证可重复执行”，关键在于你如何在过程里做存在性判断和条件分支——不加判断就 CREATE PROCEDURE，第二次执行必然报错 ERROR 1304 (42000): PROCEDURE xxx already exists。
CREATE PROCEDURE 前必须用 DROP IF EXISTS
MySQL 8.0.13+ 支持 DROP PROCEDURE IF EXISTS，这是最简明的前置清理方式。低版本（如 5.7）不支持该语法，必须手动查表再删。
- 推荐写法（MySQL ≥ 8.0.13）：
DROP PROCEDURE IF EXISTS add_column_if_not_exists; DELIMITER // CREATE PROCEDURE add_column_if_not_exists(...) BEGIN -- 逻辑体 END // DELIMITER ;
- 兼容旧版写法（MySQL 5.7）：
SELECT COUNT(*) INTO @exists FROM mysql.proc WHERE name = 'add_column_if_not_exists' AND db = DATABASE(); SET @sql = IF(@exists > 0, 'DROP PROCEDURE add_column_if_not_exists', 'SELECT 1'); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt;
- 注意：
mysql.proc表在 MySQL 8.0 中已被移除，所以该兼容写法仅适用于 5.7 及更早版本
字段/索引/约束操作必须查 information_schema
所有结构变更（ADD COLUMN、ADD INDEX、MODIFY COLUMN）都得先确认对象是否已存在，否则 ALTER TABLE 直接失败。核心依据是 information_schema.COLUMNS、information_schema.STATISTICS、information_schema.KEY_COLUMN_USAGE。
- 查字段是否存在：
SELECT COUNT(*) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'user' AND COLUMN_NAME = 'gender';
- 查索引是否存在（注意：索引名可能跨表重名，需限定
TABLE_NAME）：SELECT COUNT(*) FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'user' AND INDEX_NAME = 'idx_email';
- 查外键约束名（
CONSTRAINT_NAME在KEY_COLUMN_USAGE中不唯一，应查INFORMATION_SCHEMA.KEY_COLUMN_USAGE或INFORMATION_SCHEMA.TABLE_CONSTRAINTS）
ALTER TABLE 语句不能直接参数化，必须用 PREPARE + EXECUTE
存储过程中无法把表名、字段名写成变量直接拼进 ALTER TABLE，否则会报语法错误。必须构造字符串 SQL，再用 PREPARE 执行。
- 错误写法：
SET @table = 'user'; ALTER TABLE @table ADD COLUMN status TINYINT DEFAULT 0; -- ❌ 语法错误
- 正确写法：
SET @table = 'user'; SET @sql = CONCAT('ALTER TABLE ', @table, ' ADD COLUMN status TINYINT DEFAULT 0'); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; - 风险点：拼接 SQL 时若变量含单引号或反引号，易引发注入或语法错误；生产环境建议对输入参数做白名单校验（如正则匹配
^[a-zA-Z0-9_]+$）
事务对 DDL 无效，别指望回滚 ALTER TABLE
MySQL 中，ALTER TABLE 是隐式提交操作，一旦执行就不可回滚。哪怕你包在 START TRANSACTION 里，执行完也会自动提交——这意味着你在存储过程中无法靠事务来“兜底”结构变更失败。
- 后果：前几条
ALTER TABLE成功，最后一条失败，脚本中途退出，数据库已处于半升级状态 - 应对方式：
– 把每个 DDL 操作封装成独立存储过程，按顺序调用，失败时人工介入
– 在调用前先用SELECT检查目标状态，确保变更必要且安全
– 避免在同一个存储过程中混合 DML 和 DDL，DDL 的原子性不可控
真正难的不是写一个能跑通的存储过程，而是让每次部署都“像第一次那样干净”。查表、拼 SQL、防注入、绕过事务限制——这些细节漏掉任何一环，上线时就可能卡在某台测试库上动弹不得。
