MySQL存储过程不支持直接写ALTER TABLE，因协议层禁止DDL预编译；必须用PREPARE+EXECUTE动态执行，并注意反引号包裹标识符、参数安全拼接、显式释放及异常处理。
MySQL存储过程里写死ALTER TABLE会直接编译失败，不是语法问题，是协议层不支持——必须走PREPARE+EXECUTE动态执行路径。
为什么ALTER TABLE在存储过程中直接写就报错
MySQL在存储过程编译阶段就校验语句类型，而ALTER TABLE、CREATE TABLE这类DDL语句不属于“可预编译的常规语句”。它隐式提交事务、触发元数据锁（MDL），且无法被存储过程上下文接纳。你看到的错误通常是：
ERROR 1312 (0A000): PROCEDURE can't return a result set in the given context-
ERROR 1243 (HY000): Unknown prepared statement handler（漏DEALLOCATE PREPARE时） -
ERROR 1064（拼SQL时少空格、漏反引号，错误位置却指向EXECUTE行）
根本原因不是你写错了SQL，而是MySQL预处理协议（prepared statement protocol）明确不支持DDL——这不是bug，是设计限制。
PREPARE+EXECUTE是最小可行模板
所有能跑通的DDL封装都得基于这个骨架，不能省略任何一环：
SET @sql = CONCAT('ALTER TABLE `', table_name, '` ADD COLUMN x INT');
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;关键细节：
-
PREPARE只接受用户变量（如@sql）或字符串字面量，**不能直接传存储过程参数**，必须先拼进@sql - 表名、字段名必须用反引号包裹，否则遇到
order、group等关键字直接报错 -
DEALLOCATE PREPARE stmt必须加，否则下次调用同名stmt会因已存在而失败 - 每次执行前建议
SET @sql = ''清空，避免残留旧SQL误执行
防注入和字段名拼接的硬约束
如果表名或字段名来自输入参数（比如IN table_name VARCHAR(64)），不能直接拼：
-- ❌ 危险：可能注入单引号或换行
SET @sql = CONCAT('ALTER TABLE ', table_name, ' ADD COLUMN ', col_name, ' INT');正确做法：
- 用
QUOTE()包裹值：CONCAT('ALTER TABLE `', table_name, '` ADD COLUMN `', col_name, '` INT') - 或手动清理：
REPLACE(REPLACE(table_name, '\'', ''), '\n', '') - 字段定义部分建议拆段拼，比如
CONCAT('id INT PRIMARY KEY, name VARCHAR(', char_len, ')')，避免INTNOT NULL这种连写错误 - 引擎、字符集别省：
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4，老环境默认可能还是MyISAM
DDL失败不会回滚，且状态难清理
这是最容易被忽略的点：DDL本身不可回滚，哪怕它在BEGIN ... END块里。一旦CREATE TABLE失败，前面成功的INSERT也不会撤回；更麻烦的是：
-
@sql变量还留着上一次拼好的字符串，下次EXECUTE可能执行错内容 - 临时表若已存在，再建就报
ERROR 1050 - 没加错误捕获，失败后存储过程静默退出，连日志都没留
务必加异常处理：
DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN INSERT INTO ddl_log VALUES (NOW(), @sql, 'failed'); RESIGNAL; END;
真正需要原子性时，别指望存储过程兜底——得在应用层检查表是否存在、字段是否已存在，再决定是否跳过，而不是靠CREATE TABLE IF NOT EXISTS硬刚。
