合并多条INSERT为单条VALUES语句可显著提升性能：仅1次SQL解析、权限校验与日志批量刷盘，网络往返从N次减为1次；建议每批1000–5000行，需配合手动事务、innodb_flush_log_at_trx_commit=0、bulk_insert_buffer_size调大及主键有序插入。
合并多条INSERT为单条VALUES语句
单条 INSERT INTO t(a,b) VALUES (1,2) 插入 1 行，和 INSERT INTO t(a,b) VALUES (1,2),(3,4),(5,6) 插入 3 行，底层执行开销差异巨大。前者触发 3 次 SQL 解析、权限校验、日志写入（binlog + redo）；后者只做 1 次解析，日志批量刷盘，网络往返也从 3 次减为 1 次。
实操建议：
- 每批控制在 1000–5000 行之间：太小起不到合并效果，太大易触发
max_allowed_packet限制或内存溢出 - 避免跨类型拼接：比如把
NULL、字符串、数字混在同一批中，可能因隐式转换导致优化器放弃批量路径 - 字段顺序必须严格一致：
INSERT INTO t(x,y) VALUES (1,'a'),(2,NULL)合法；INSERT INTO t(x,y) VALUES (1,'a'),(NULL,2)虽语法通过，但部分驱动会报类型不匹配
显式用START TRANSACTION包裹批量插入
默认 autocommit=1 时，每条 INSERT 都自动开启并提交事务，产生完整 redo + binlog + fsync 流程。改成手动事务后，所有插入共享一个事务上下文，仅在 COMMIT 时刷盘一次——这是性能跃升的关键环节。
常见错误现象：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 程序没报错但插入极慢：检查是否误用了
autocommit=True或 ORM 默认行为（如 Django 的atomic未生效） - 事务超时中断：大批量插入耗时超过
innodb_lock_wait_timeout或wait_timeout，需提前调大 - 锁表阻塞其他业务：长事务期间持有表级/行级锁，建议在低峰期执行，或拆成更小批次（如每次 5000 行 +
SLEEP(0.1)）
配合关键MySQL配置调整
光靠 SQL 写法优化不够，底层配置不匹配会拖垮效果。以下三项必须检查：
-
innodb_flush_log_at_trx_commit = 0：事务提交时不强制刷 redo log 到磁盘，仅写入 OS cache，速度可提升 3–5 倍；但断电会丢失最多 1 秒数据——仅限导入场景临时启用 -
bulk_insert_buffer_size：专为批量插入设计的缓存，默认 8MB，大数据量时可设为 64–256MB，直接作用于INSERT ... VALUES和LOAD DATA -
innodb_buffer_pool_size：确保其值 ≥ 数据总大小的 50%（尤其主键有序插入时），否则频繁 page fault 会抵消所有优化
主键顺序插入能减少B+树分裂
InnoDB 表按主键聚簇，如果插入的主键值随机（如 UUID、雪花 ID 无序写入），会导致频繁页分裂、数据碎片、缓冲池命中率下降。而按主键递增插入（如自增 ID、时间戳前缀），新记录总追加到 B+ 树最右叶节点，物理写入连续，效率接近线性增长。
使用场景：
- 日志类表、事件表：用
created_at或event_time作联合主键首列 - 迁移旧数据：先
ORDER BY id再导出，再用LOAD DATA或批量 INSERT - 避免陷阱：不要在已有大量数据的表上突然插入极小 ID（如
id=1），会强制回溯查找位置，比随机还慢
真正卡住性能的往往不是某一行代码，而是事务边界没控好、配置没对齐、或者主键乱序导致的隐式 IO 放大。这些点单独看简单，但组合出现时，10 万行插入可能从 2 秒变成 2 分钟。
