批量INSERT性能远高于单条循环插入，根本原因是绕开锁粒度碎片化、SQL重复解析、日志高频刷盘和网络往返放大四重开销；多值INSERT仅一次解析与刷盘，显式事务包裹多批可进一步减少开销。
批量 INSERT 性能远高于单条循环插入，根本原因不是“数据库更聪明”，而是它绕开了循环带来的锁粒度碎片化、SQL 解析重复、日志刷盘高频和网络往返放大这四重开销。
单条循环INSERT每行都触发完整事务生命周期
默认 autocommit=1 时，每次 INSERT 都是独立事务：加锁 → 写 redo log → 刷盘（若 innodb_flush_log_at_trx_commit=1）→ 提交 → 释放锁。10 万次 = 10 万次锁登记/清理、10 万次日志 fsync、10 万次网络 RTT（尤其跨机房时，1ms 延迟 × 10 万 = 100 秒纯等待）。
常见错误现象：
- 应用日志显示“插入耗时稳定在 8–12ms”，但总耗时线性增长，后期 CPU 和磁盘 IO 并不高——瓶颈其实在网络和锁管理器
- 表上有唯一索引时，
SHOW ENGINE INNODB STATUS中频繁出现lock wait timeout或大量waiting for table metadata lock
多值INSERT只做一次SQL解析和一次日志刷盘
INSERT INTO t(a,b) VALUES (1,2), (3,4), (5,6) 是一条语句，MySQL 只执行一次词法/语法解析、一次执行计划生成、一次权限校验，redo log 合并写入，事务提交也仅一次。
关键参数影响：
-
max_allowed_packet限制单条 SQL 长度（默认 4MB），实际建议每批控制在1000–5000行，具体取决于字段长度；超长会报错Packet too large - 每行含
TEXT或BLOB时，内存临时占用陡增，可能触发tmp_table_size不足，降级为磁盘临时表，性能断崖下跌 - 不加事务包装的多值
INSERT已比单条快，但显式用BEGIN; ... COMMIT;包裹多批，可再省掉事务启动/关闭的固定开销
锁行为差异直接决定并发吞吐
单条循环：每行独立加 X 锁、立刻释放，锁管理器反复登记/唤醒；高并发下易形成“锁链”——A 卡在第 100 行，后面 99 行全阻塞，其他会话更新同一范围直接超时。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
多值 INSERT：InnoDB 一次性评估所有待插行的位置，只对涉及的索引页和目标行加锁，锁持续到语句结束；有唯一索引时，冲突检查也只做一次，不是 N 次 B+ 树搜索。
容易踩的坑：
- 误以为“用了多值 INSERT 就万事大吉”，结果每批都自动提交，锁开销仍接近单条循环
- 单事务插入 50 万行，
undo log膨胀、主从延迟飙升，甚至被innodb_lock_wait_timeout中断（该参数按事务计，不是按语句） - 忽略间隙锁（gap lock）影响：多值
INSERT仍会为整个插入区间加间隙锁，若并发写入相邻范围，照样阻塞
LOAD DATA INFILE 是真正的“降维打击”
它完全绕过 SQL 层：不解析、不校验权限、不走查询缓存、不生成执行计划，直接读文件、切分字段、构造内存行、批量刷入引擎。百万行导入常在 5–10 秒完成，而等量 INSERT 即使加事务也要 60 秒以上。
但硬约束明显：
- 文件必须在 MySQL 服务端本地，或客户端启用
local_infile=ON且服务端配置secure_file_priv允许路径 - 编码不匹配（如 CSV 是 UTF-8 BOM，表是
utf8mb4）会导致乱码，错误信息常为Incorrect string value - 字段分隔符、换行符、转义字符（如
\N表 NULL）必须严格匹配，否则整批失败，且报错位置难定位
真正容易被忽略的是：批量插入的收益不来自“语法糖”，而来自对数据库底层机制（锁管理、日志刷盘、SQL 解析）的规避策略。哪怕只是把 1000 次单条 INSERT 改成 10 批多值 INSERT 并包进一个事务，性能也能提升一个数量级——前提是别让每批又各自 COMMIT。
