会，CREATE TABLE AS SELECT 只复制列定义和数据，彻底丢失主键、索引、外键、约束、注释、AUTO_INCREMENT、分区、触发器等全部元数据，本质是结果集快照而非结构克隆。
CREATE TABLE AS SELECT 会丢索引和约束吗
会，而且丢得非常彻底。CREATE TABLE new_table AS SELECT * FROM old_table 只复制列定义（含数据类型、是否为 NULL、默认值表达式）和数据，其余全部清零：主键、外键、普通索引、唯一约束、FULLTEXT/SPATIAL 索引、触发器、分区、AUTO_INCREMENT 当前值、表注释、列生成表达式（GENERATED COLUMN）依赖的函数上下文——全都不保留。
它本质是“按结果集反推建表”，不是“按原表元数据重建”。所以别指望它能用于生产环境的完整克隆，只适合快速生成一份带数据的结构快照，比如临时分析表或导出中间表。
什么时候该用 CREATE TABLE AS SELECT
适用场景很窄，但确实高效：
- 需要立即拿到一份带当前数据的副本，且后续只读或只做简单计算（比如
SELECT COUNT(*)、GROUP BY聚合） - 目标表名要动态生成（如带时间戳：
logs_20260509），不想手写 DDL - 只复制部分字段或加计算列（例如
CREATE TABLE user_summary AS SELECT id, name, created_at, DATE(created_at) AS day FROM users WHERE status = 'active'） - 跨库克隆时不想导出再导入（前提是两个库在同一个 MySQL 实例里）
不适用场景：需要主键保证唯一性、要建索引加速查询、要外键维持引用完整性、要保留 AUTO_INCREMENT 值——这些都得额外补操作。
常见错误现象与避坑点
执行后发现查得慢、插入报错、或者 SHOW CREATE TABLE 一看全是空的 KEY 定义，基本就是踩了下面这些坑：
-
ERROR 1075 (42000): Incorrect table definition; there can be only one auto-increment column：原表有多个自增列，而AS SELECT会把所有自增属性都丢掉，但如果你在 SELECT 中写了多个id+0类似表达式，可能意外触发隐式列生成逻辑，引发冲突 - 新表没有主键 →
INSERT或UPDATE时无法用WHERE高效定位行；mysqldump导出时可能跳过该表（取决于 --skip-triggers 等参数） - 字符集降级：原表是
utf8mb4_0900_as_cs，新表可能变成utf8mb4_0900_ai_ci（尤其在低版本客户端连接时），导致排序行为不一致 - 列注释丢失：
COMMENT '用户昵称'不会出现在新表里，连information_schema.COLUMNS.COLUMN_COMMENT都为空 - 浮点列精度漂移：
DECIMAL(10,2)在某些旧版本中可能被识别为DOUBLE，造成数值截断（需验证DESCRIBE new_table）
想保留索引？别用 AS SELECT，改用 LIKE + INSERT
如果必须保留主键、索引、非空约束等结构要素，CREATE TABLE new_table LIKE old_table 是更稳妥的起点。它能复制：
- 所有列定义（含
NOT NULL、DEFAULT、COMMENT） - 主键、唯一索引、普通索引（但不包括
FULLTEXT和SPATIAL） - 字符集、排序规则、存储引擎、
AUTO_INCREMENT初始值（注意：不是当前值！）
之后再执行 INSERT INTO new_table SELECT * FROM old_table 补数据。两步拆开的好处是：可加 WHERE 过滤、可分批提交（避免长事务）、可提前 ALTER TABLE 调整新表结构（比如删掉某个大索引再插数据）。
真正容易被忽略的是：LIKE 执行期间，原表不能被 DDL 修改（如 ALTER TABLE），否则可能报 ERROR 1146 (42S02): Table doesn't exist —— 因为它依赖 INFORMATION_SCHEMA 的瞬时快照，不是实时读取表定义。
