为什么导入前删索引比禁用更可靠
MySQL 没有真正意义上的“临时禁用索引”机制（
和
仅对 MyISAM 有效，InnoDB 完全不支持）。很多人试过
，结果发现对 InnoDB 表毫无作用，甚至报错
。这不是操作姿势问题，是引擎限制。
实际可行路径只有两条：删索引再重建，或从一开始就不用建索引。前者更可控，后者适合纯 ETL 场景。
后导入，再
，能避免每行插入都触发 B+ 树分裂和排序
唯一索引（
）不能靠
绕过约束检查，删了才能跳过重复校验开销
如果表已有大量数据，
在导入后执行，MySQL 5.7+ 会自动用 sort-based 算法，比边插边建快 3–5 倍
批量导入时如何保留主键但跳过二级索引
主键（聚簇索引）无法删除，但二级索引可以按需剥离。关键是识别哪些索引真正在拖慢导入——通常是
、
、
这类高频查询字段的单列索引，而非联合索引本身。
执行前先查清楚要动哪些索引：
用
逐个删二级索引，别用
别名写法，容易误删
导入完成后再用
重建，注意字符集和排序规则要和原索引一致（比如
）
如果原索引带
或
属性，重建时得手动补上，否则应用层 ORM 可能读不到元数据
LOAD DATA INFILE 导入前必须调的三个参数
即使删了索引，
默认仍可能被日志、缓冲、锁机制拖慢。这三个参数不调，吞吐量卡在 2k 行/秒左右；调完轻松上 2w+ 行/秒（SSD + 16G 内存环境）。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
关掉唯一检查：
—— 否则每行都要扫二级索引判断冲突
关掉外键检查：
—— 避免每次插入都去关联表查约束
加大日志缓冲：
（64MB），防止频繁刷 log buffer
注意：这些是会话级设置，只对当前连接生效，导入完记得恢复：
重建索引时最耗时的其实是统计信息更新
很多人以为
花的时间全是建树，其实大头在最后一步：InnoDB 自动触发
更新统计信息。对于亿级表，这步可能比建索引还慢，且阻塞 DML。
可以跳过它：
（MySQL 5.6+），但必须加
才真正生效：
先执行：
再建索引
之后手动跑一次
（选低峰期）
漏掉
，建完索引瞬间就会触发统计更新，前面所有优化白做
DROP INDEXDISABLE KEYSALTER TABLE ... DISABLE KEYSERROR 1031 (HY000): Table storage engine for 't' doesn't have this optionDROP INDEXCREATE INDEXUNIQUE KEYDISABLE KEYSALTER TABLE ... ADD INDEXcreated_atstatususer_idSHOW INDEX FROM orders WHERE Key_name != 'PRIMARY';DROP INDEX idx_status ON orders;ALTER TABLE orders DROP KEY ...CREATE INDEX idx_status ON orders(status);utf8mb4_0900_as_csCOMMENTVISIBLELOAD DATA INFILESET unique_checks = 0;SET foreign_key_checks = 0;SET innodb_log_buffer_size = 64*1024*1024;SET unique_checks = 1; SET foreign_key_checks = 1;CREATE INDEXANALYZE TABLECREATE INDEX idx_user ON orders(user_id) ALGORITHM=INPLACE, LOCK=NONE;STATS_AUTO_RECALC=0ALTER TABLE orders STATS_AUTO_RECALC=0;ANALYZE TABLE orders;STATS_AUTO_RECALC=0