先说一个核心结论：CREATE TABLE AS SELECT 无法复制表结构中的关键元数据。它只能拷贝列定义和数据，而主键、索引、AUTO_INCREMENT、字符集、字段注释等结构信息，全部丢失。这条命令本质上是“根据查询结果反推建表”，不会读取原表的 information_schema 元数据，所以无法承担真正意义上的数据库备份任务。它更适合用于临时快照，生产环境中请谨慎使用。
为什么 CREATE TABLE AS SELECT 会导致主键和索引丢失
执行后通过 SHOW CREATE TABLE new_table 可以直观看到：PRIMARY KEY 消失了，KEY 也不复存在，AUTO_INCREMENT 字段直接降级为普通整数。举个例子：
- 原表
id INT AUTO_INCREMENT PRIMARY KEY→ 新表变成id INT，插入时很可能报Field 'id' doesn't have a default value错误，因为自增属性丢失，引擎无法自动生成递增值。 UNIQUE KEY idx_email (email)消失 → 后续向新表插入重复邮箱时不会报错，原本的查重逻辑彻底失效，数据一致性面临风险。- 字符集可能被降级为
latin1_swedish_ci或utf8mb4_0900_ai_ci，直接影响中文排序、大小写敏感行为。你以为使用了全球通用的utf8mb4，结果新表默默变成latin1，线上查询比对全部混乱。 - 遇到
GENERATED COLUMN或CHECK约束时，CREATE TABLE AS SELECT会直接报错退出，完全不兼容。
什么场景下可以临时使用 CREATE TABLE AS SELECT
只有少数临时场景能够容忍这种缺陷，但你必须清楚后续需要手动补救：
- 导出带时间戳的分析快照，例如
logs_20260607，仅供只读聚合使用，不涉及写操作和约束校验。 - 作为 ETL 中间表，后续会清洗数据再写入目标表，只是临时承载传输量。
- 测试环境快速造数据，字段少、无业务校验逻辑，用完即删。
- 跨库克隆（同实例），但必须确认目标库没有同名表，否则会抛出
ERROR 1050 (42S01)。
大表慎用：CREATE TABLE AS SELECT 是单事务执行，可能撑爆 innodb_log_file_size，或触发长事务告警；执行前务必添加 WHERE 或 LIMIT 控制数据量，避免一次拖垮整个数据库。
如果想保留主键和索引，必须使用 CREATE TABLE LIKE + INSERT
这才是生产环境下唯一稳妥的全量复制路径。具体步骤如下：
CREATE TABLE new_t LIKE old_t会完整复制：NOT NULL、DEFAULT、AUTO_INCREMENT、所有索引（主键/唯一/全文）、字符集、排序规则、自增起始值。一句话，除了外键和注释，能复制的元数据都保留了。- 但它不会复制：
FOREIGN KEY、触发器、表注释、分区定义。外键需要手动重建，注释需要补一句ALTER TABLE new_t COMMENT = 'xxx'。 INSERT INTO new_t SELECT * FROM old_t要求字段顺序和类型严格一致；如果不匹配，必须显式列出字段：INSERT INTO new_t (id, name) SELECT id, name FROM old_t，否则会报错。- 大表导入前建议调大会话参数：
SET SESSION sort_buffer_size = 16M，避免因排序缓存不足导致执行缓慢或失败。
最容易忽略的是验证环节：许多人执行完 CREATE TABLE AS SELECT 后不检查 SHOW CREATE TABLE，就直接上线使用。结果主键缺失、索引丢失、字符集异常——这些问题在线上暴露时往往已经造成数据不一致或性能雪崩。所以，哪怕只是临时使用，也请养成随手检查的习惯。
