MySQL存储过程在日常批量数据处理和运维脚本中非常常见，但不少人在过程体里直接写DROP TABLE或者CREATE INDEX时，会立刻遇到编译错误。这并不是MySQL故意限制功能，而是它的SQL执行模型和存储过程机制共同决定的。下面我们先看一张示意图，帮助理解整体结构。
为什么存储过程不能直接执行DDL
MySQL的存储过程在创建时就要经过解析、编译和优化阶段。在这个阶段，服务器需要明确过程体内每一条语句的对象和结构。DDL语句（比如CREATE TABLE、ALTER TABLE、DROP VIEW）会修改数据字典和表结构元数据，而元数据在编译期是不可预测的。如果允许直接写死DDL，一旦表被删掉或者字段被改掉，已经编译好的过程就会指向不存在的对象，导致严重的一致性问题。
另一个关键点是隐式提交。在MySQL中，几乎所有DDL都会隐式地提交当前事务。存储过程通常运行在事务上下文里，直接执行DDL会打断事务逻辑，让调用方无法用ROLLBACK回退前面的DML操作。因此MySQL的语法解析器直接禁止在存储过程体里出现静态DDL文本，从语言层面规避这种混乱。
通过动态SQL包装DDL
解决静态DDL限制的标准做法是使用动态SQL。MySQL提供了PREPARE、EXECUTE和DEALLOCATE PREPARE语句，可以把DDL写成字符串，在运行时再解析执行。因为字符串在编译期只是普通文本，不会触发对象检查，所以能顺利通过存储过程的创建。
下面示例展示如何在存储过程里动态创建一张表：
DELIMITER $$
CREATE PROCEDURE create_log_table(IN tbl_name VARCHAR(64))
BEGIN
-- 拼接DDL字符串，表名通过参数传入
SET @ddl_sql = CONCAT('CREATE TABLE ', tbl_name, ' (id INT PRIMARY KEY, msg VARCHAR(255))');
-- 预编译动态语句
PREPARE stmt FROM @ddl_sql;
-- 执行动态语句
EXECUTE stmt;
-- 释放预编译资源
DEALLOCATE PREPARE stmt;
END$$
DELIMITER ;
这种写法把DDL延后到调用过程时才真正生效，避开了编译期限制。不过要注意，动态SQL里的表名和字段名必须通过CONCAT拼接，不能作为参数占位符绑定，因为MySQL只允许在PREPARE里用问号占位符替代值，不能替代标识符。如果表名来自用户输入，一定要做白名单校验，防止SQL注入。
动态SQL同样会触发DDL的隐式提交，所以即便用PREPARE包装，它依然无法在事务里回滚。如果业务要求建表和插数据原子完成，就需要把建表放在过程外，或者在应用层用脚本顺序控制。
通过事务控制与外层调度解决
如果你的场景是“先改结构再写数据”，而且希望失败时整体还原，那么单纯在存储过程内执行DDL并不能满足事务回滚需求。更稳妥的方案是把DDL和DML拆分：由外层程序或事件调度器先执行DDL，再调用存储过程做数据操作。
例如，可以用一个Shell脚本或者Java程序先发CREATE TABLE，成功后再调用下面的存储过程写入初始数据：
DELIMITER $$
CREATE PROCEDURE init_log_data(IN tbl_name VARCHAR(64))
BEGIN
-- 假设表已由外层创建，这里只做DML
SET @insert_sql = CONCAT('INSERT INTO ', tbl_name, ' (id, msg) VALUES (1, ''init'')');
PREPARE stmt FROM @insert_sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END$$
DELIMITER ;
这种分层方式让DDL在存储过程之外、应用可控的事务边界外完成，而存储过程专注于批量DML逻辑，既清晰又安全。对于需要定期自动建分表的系统，常用事件调度器在每月一号执行CREATE TABLE，然后过程往新表里导数据，避免过程内直接DDL带来的元数据锁竞争。
两种方案对比与选择
动态SQL包装适合过程内部需要根据运行时条件灵活建对象的情况，比如通用的归档清理过程。它的优势是逻辑内聚，调用方无感知；劣势是调试稍麻烦，且仍有隐式提交。
外层事务控制适合强一致性、结构变更频繁但与数据写入分离的场景。它把风险点移出过程，方便用数据库外的事务框架统一管理。实际项目中，往往两者结合：用脚本做结构迁移，用存储过程做高性能数据吞吐。
| 方案 | 是否可回滚 | 适用场景 |
|---|---|---|
| 动态SQL包装DDL | 否，隐式提交 | 过程内灵活建表、自动分表 |
| 外层调度加过程DML | DDL外不可回滚，DML可控 | 结构稳定、数据批量处理 |
常见误区与注意点
有人尝试用DECLARE CONTINUE HANDLER捕获DDL错误来实现回滚，这是无效的，因为DDL隐式提交后，前面的DML已经落地。还有人把DDL写在函数而不是过程里，MySQL对函数的限制更严，连动态SQL都难以使用，应当避免。
在编写涉及DDL的自动化任务时，建议先在小表上用动态SQL测试元数据锁占用时间，避免在生产高峰执行ALTER TABLE类操作。结合pt-online-schema-change等工具，可以进一步降低存储过程外DDL对线上读写的影响。