单条INSERT VALUES语句建议不超过500行，因max_allowed_packet限制、解析耗时增加及整批回滚风险；需显式事务控制、字段值加引号、主键有序插入并预校验数据。
INSERT INTO 一次性插入多条数据，关键不在于“能不能”，而在于“怎么分批、怎么控制事务、怎么避开隐式转换和长度限制”。盲目堆几千行进一个 VALUES 语句，反而可能触发超时、截断或解析失败。
用多值 VALUES 语法时，单条语句最多塞多少行？
MySQL 默认单条语句不宜超过 1000–2000 行（约 1–2MB），原因有三：
-
max_allowed_packet限制（默认 64MB，但实际建议留余量）； - SQL 解析耗时随长度非线性增长；
- 出错时整条语句回滚，重试成本高。
PostgreSQL 和 SQL Server 对单语句行数更敏感：PostgreSQL 建议单次不超过 5000 行，SQL Server 在大事务下易触发锁升级（LOCK_ESCALATION）。实操中，**500 行/批是跨数据库较稳妥的起点**。
为什么加了 START TRANSACTION 还是慢？
手动开事务只是第一步，真正卡点常在：
- 没关自动提交（
AUTOCOMMIT=1时，START TRANSACTION后仍需显式COMMIT，否则连接挂起）； - 每批后没及时
COMMIT，导致 undo log 持续膨胀、锁持有时间拉长； - 批量语句之间穿插了
SELECT或其他 DML，破坏了事务内纯写入的效率优势。
正确节奏是：START TRANSACTION → 多条 INSERT ... VALUES (...),(...),... → COMMIT。中间不要混杂查询或更新。
字符串和日期字段不加引号会怎样？
不加引号不是语法错误，而是隐式转换陷阱：
-
INSERT INTO t (dt) VALUES (2025-10-14)→ 数据库当数值算，结果是2025 - 10 - 14 = 2001，存成整数 2001； -
INSERT INTO t (name) VALUES (Alice)→ 触发列名解析，报错Unknown column 'Alice' in 'field list'； - 即使侥幸通过（如某些 MySQL 兼容模式），后续
WHERE dt = '2025-10-14'会因类型不一致无法走索引。
所有字符串、日期、时间字面量，**必须用单引号包裹**，这是可读性和健壮性的底线。
主键乱序插入真的影响性能？
影响显著，尤其对 InnoDB（MySQL）和聚集索引表（SQL Server）：
- 主键无序 → 新行要插入到页中间 → 频繁页分裂 → 磁盘随机写增多；
- 二级索引更新代价同步上升（每行变更都要更新所有二级索引项）；
- 测试显示：10 万条主键随机插入比顺序插入慢 3–5 倍。
如果数据源本身无序，插入前先按主键排序（如用 ORDER BY id 子查询或客户端预排序），比硬扛慢插入更省事。别指望数据库帮你“自动优化顺序”。
批量插入不是拼手速，而是平衡语句长度、事务粒度、数据格式和存储引擎特性的过程。最容易被跳过的其实是数据预校验——比如提前检查字符串是否含未转义单引号、日期格式是否全为 'YYYY-MM-DD HH:MM:SS'，这类问题一旦进到 VALUES 列表里，报错位置难定位，修复成本远高于前置过滤。
