MySQL存储过程无法一键复制表结构和数据，因CREATE TABLE ... LIKE等DDL语句不支持动态执行，且存在表名不能变量、PREPARE不支持DDL、无事务回滚、无法自动推导字符集索引等硬性限制。
不能直接用存储过程“一键复制表结构+数据”，MySQL 存储过程不支持动态执行 CREATE TABLE ... LIKE 或 INSERT INTO ... SELECT 这类语句（除非拼 SQL 字符串 + PREPARE/EXECUTE），且无法规避语法限制和权限问题。真要自动化，得绕开存储过程本身，用更可控的方式。
为什么不能写个简单存储过程直接复制表
MySQL 存储过程里，CREATE TABLE new_t LIKE old_t 这类语句必须是静态的——表名不能是变量；若尝试用 CONCAT 拼接再执行，会触发以下硬性限制：
-
PREPARE不支持CREATE、DROP、ALTER等 DDL 语句（MySQL 8.0+ 仍不支持） - 即使绕过（如用客户端脚本预生成 SQL），存储过程也无法跨库访问原表元数据来自动推导字符集、索引等细节
- 执行时若目标表已存在，
CREATE TABLE ... LIKE直接报错ERROR 1050 (42S01)，而存储过程里IF NOT EXISTS对LIKE无效 - 没有事务回滚能力：前半步建表成功、后半步插入失败，表就卡在半成品状态
真正可行的“自动化复制”路径：用事件或外部脚本驱动
想让复制动作可复用、可调度，推荐以下两种落地方式，而非硬塞进存储过程：
-
用 MySQL Event + 预置 SQL 文件：把
CREATE TABLE new_t LIKE old_t和INSERT INTO new_t SELECT * FROM old_t写成独立 SQL 脚本，用系统定时任务（如 Linuxcron）调用mysql -e执行；Event 本身只适合简单INSERT/UPDATE，不适合建表 -
用 Python/Shell 封装逻辑：先查
information_schema.TABLES获取原表引擎、字符集；再拼出带CHARSET和COLLATE的CREATE TABLE ... LIKE；最后执行INSERT；还能加异常捕获、日志、分批控制（如LIMIT分页） - 若坚持用数据库内机制，可用
mysqldump --no-create-info导出数据 +SHOW CREATE TABLE提取 DDL，合并后用source执行——但这已脱离“存储过程”范畴
如果非要用存储过程，只能做有限封装
仅适用于“结构完全已知、目标表名固定、且只需复制数据”的极简场景，例如：
DELIMITER $$
CREATE PROCEDURE copy_data_only(IN src_table VARCHAR(64), IN dst_table VARCHAR(64))
BEGIN
SET @sql = CONCAT('INSERT INTO ', dst_table, ' SELECT * FROM ', src_table);
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END$$
DELIMITER ;注意：src_table 和 dst_table 必须已存在，且字段顺序、类型严格一致；不处理任何结构复制，也不校验主键/索引是否匹配；大表执行时可能锁死源表。
真正需要保约束的复制，别碰存储过程封装——它解决不了 LIKE 的原子性缺失、外键不复制、字符集继承异常这些底层问题。手动跑两行 SQL 或写个轻量脚本，反而更稳、更透明、更容易调试。
