单条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 列表里，报错位置难定位，修复成本远高于前置过滤。