为什么 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 挤出旧页——这些开关不开，再好的语句也白搭。
