ALTER TABLE ... ENGINE=InnoDB对千万级表会触发全表COPY重建，耗时数小时且锁表；应拆分为禁用约束→删二级索引→导入数据→恢复约束→逐个建索引，并注意版本、字符集及配置兼容性。
为什么不能直接用 ALTER TABLE ... ENGINE=InnoDB 重建索引
这条命令看似“一键重建”，但对千万级表来说，它会触发全表重建：逐行读取、重新排序、写入新页、重建所有索引——本质是隐式执行了一次 COPY 算法。即使 MySQL 5.7+ 默认尝试 ALGORITHM=INPLACE，只要涉及二级索引重建（尤其是多列、长字段），仍可能退化为拷贝模式，耗时数小时且锁表风险高。更关键的是，它无法跳过唯一性/外键校验的开销，而迁移场景下这些约束往往已由源端保证。
真正有效的重建路径：删索引 → 导入 → 再建
迁移后重建二级索引，核心不是“怎么建”，而是“什么时候建、以什么顺序建”。千万级表必须把索引重建拆离主数据导入流程：
- 迁移前，在目标表上执行
SET FOREIGN_KEY_CHECKS = 0和SET UNIQUE_CHECKS = 0（注意：仅对当前会话有效，需在导入连接中显式设置） - 用
DROP INDEX idx_name ON t1删除所有非主键二级索引（主键聚簇索引不能删，也不应删） - 用
LOAD DATA LOCAL INFILE或逻辑导入工具完成数据加载（此时无索引、无约束校验，速度最快） - 导入完成后，**立刻**执行
SET UNIQUE_CHECKS = 1和SET FOREIGN_KEY_CHECKS = 1，再逐个执行CREATE INDEX
这个顺序不能颠倒：先恢复约束检查，再建索引，否则建索引过程中若发生唯一冲突，会因约束未启用而静默失败或产生脏数据。
CREATE INDEX 的并发与参数控制
单条 CREATE INDEX 在 InnoDB 中默认是在线操作（ALGORITHM=INPLACE, LOCK=NONE），但并发建多个索引会争抢 IO 和 CPU，反而拖慢整体进度。实际操作中建议：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 按查询频率和字段选择性排序，优先建高频 WHERE 条件中的单列索引（如
user_id、status），再建复合索引 - 避免在一条语句中建多个索引（如
ALTER TABLE t ADD INDEX a(x), ADD INDEX b(y)），MySQL 会串行处理，且任一失败需全部回滚 - 对长文本字段建前缀索引时，用
CREATE INDEX idx_content ON t(content(100))控制长度，避免 B+ 树节点过大 - 监控
information_schema.INNODB_METRICS中的dml_inserts和index_page_reorgs，确认索引构建未引发严重页分裂
容易被忽略的兼容性陷阱
重建索引不是纯 SQL 操作，它受 MySQL 版本、存储引擎配置、甚至字符集影响：
- MySQL 8.0+ 默认启用
innodb_strict_mode，若索引字段含 NULL 值且定义为NOT NULL，CREATE INDEX会直接报错ERROR 1138，需提前清洗或改用ALGORITHM=COPY - 使用 utf8mb4 字符集时，联合索引总长度上限为 3072 字节（而非老版本的 767），超长索引会静默截断，需用
SHOW CREATE TABLE核对实际生效的列长度 - 如果目标库开启了
sql_log_bin=0（常见于从库迁移），CREATE INDEX不写 binlog，主从一致性需额外校验 - 某些云数据库（如 GaussDB(for MySQL)）支持并行索引创建（
PARALLEL=4参数），但原生 MySQL 不识别该语法，直接执行会报错ERROR 1064
重建二级索引最耗时的环节从来不是 SQL 本身，而是你没检查的那一行 SHOW VARIABLES LIKE 'innodb_%' 输出里的配置项。
