INSERT 慢主因是锁和事务机制：未走索引、间隙锁、事务未提交导致锁等待；批量插入应多值合并、禁用自动提交、调优 innodb_flush_log_at_trx_commit=2 等参数。
为什么 INSERT 会慢？先看锁和事务在干什么
并发写入卡顿，80% 不是磁盘或 CPU 瓶颈，而是 INSERT 被隐式锁住：InnoDB 默认走行级锁，但若没走索引、或插入间隙（gap lock）、或事务未及时提交，就会触发锁等待甚至死锁。尤其批量插入时，每条 INSERT 单独提交，等于反复加锁/刷日志/刷脏页。
- 用
SHOW ENGINE INNODB STATUS\G查TRANSACTIONS段，看是否有大量LOCK WAIT或waiting for table metadata lock - 检查插入语句是否命中主键或唯一索引——没索引的
INSERT ... SELECT或REPLACE INTO容易退化为表级扫描+锁 - 确认事务隔离级别：
REPEATABLE READ下 gap lock 更激进，高并发插入相同范围值时极易冲突；可临时试READ COMMITTED（需业务能接受幻读）
批量写入必须用 INSERT INTO ... VALUES (...), (...), (...)
单条 INSERT 和多值批量插入的性能差 5–20 倍，核心在于减少网络往返、日志刷盘次数和锁获取频次。但要注意分批大小——太大触发内存溢出或锁升级，太小失去批量意义。
- 单次批量控制在
1000行以内（innodb_log_file_size和max_allowed_packet也限制上限） - 避免拼接超长 SQL：Python 用
executemany()，Java 用addBatch()，让驱动自动拆包 - 禁用自动提交：
SET autocommit = 0，所有批量插入完成后COMMIT—— 但注意事务不能太久，否则阻塞 MVCC 清理
LOAD DATA INFILE 是最快路径，但权限和路径常被忽略
比批量 INSERT 快 5–10 倍，本质是服务端直接读文件、跳过 SQL 解析层。但它对环境要求苛刻，不是“一写就快”。
- 必须确保 MySQL 配置开启：
secure_file_priv不为空（查SELECT @@secure_file_priv），且你的 CSV 文件放在该目录下 - 客户端执行
LOAD DATA LOCAL INFILE需显式启用（MySQL 8.0+ 默认关闭），连接时加参数--local-infile=1，并确认服务端local_infile=ON - 字段分隔符、NULL 处理要严格匹配：
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'，否则整批失败
写入瓶颈真在磁盘？先调这几个关键参数
即使 SQL 和事务优化到位，innodb_flush_log_at_trx_commit、sync_binlog、innodb_buffer_pool_size 这三个参数不调，SSD 也跑不满。
-
innodb_flush_log_at_trx_commit = 2：日志刷到 OS 缓存而非磁盘，崩溃可能丢 1 秒数据，但写入吞吐翻倍（线上可接受，金融类除外） -
sync_binlog = 0或1000：避免每次事务都强制刷 binlog，异步刷更稳；若用 GTID 或主从强一致，至少设为1000 -
innodb_buffer_pool_size至少占物理内存 70%，否则频繁刷脏页 + 磁盘 IO 成瓶颈
SET GLOBAL innodb_flush_log_at_trx_commit = 2; SET GLOBAL sync_binlog = 1000; -- 注意：buffer_pool_size 需重启生效，不可动态改
真正卡住的地方，往往不是你怎么写 SQL，而是你没意识到 MySQL 正在等磁盘落盘、等 binlog 同步、等 buffer pool 挤出旧页——这些开关不开，再好的语句也白搭。
