单条insert拖慢批量写入，因每条都走完整事务流程（校验、写日志、刷盘、更新索引），1000次即1000倍开销；改用显式事务包裹+多值insert可大幅降低日志写入和索引维护次数。
为什么单条 INSERT 会拖慢批量写入
每次 INSERT INTO ... VALUES (...) 都是一次独立事务（除非显式开启事务），数据库要校验约束、写日志、刷盘、更新索引——每条都走完整流程。1000 条单条插入，可能耗时数秒甚至更久；而合并成一批，开销基本只多一次日志写入和一次索引维护。
常见错误现象：INSERT 循环里没包事务，或用了 AUTOCOMMIT=ON 却没意识到它在后台默默提交每一条。
实操建议：
- 务必用显式事务包裹：先
BEGIN TRANSACTION（或START TRANSACTION），所有INSERT后再COMMIT - MySQL 用户注意：默认
autocommit=1，需临时关掉：SET autocommit = 0 - PostgreSQL 用户注意：
BEGIN后必须配COMMIT或ROLLBACK，否则连接会卡在事务中
怎么写一条 INSERT 批量插入多行
标准 SQL 支持在单条 INSERT 中列出多组值，这是最轻量、兼容性最好的方式，无需额外扩展或驱动支持。
示例（MySQL / PostgreSQL / SQLite 均可用）：
INSERT INTO users (name, email, created_at)
VALUES
('Alice', 'alice@example.com', '2024-01-01'),
('Bob', 'bob@example.com', '2024-01-02'),
('Charlie', 'charlie@example.com', '2024-01-03');
关键限制与建议：
- 单条语句的值行数不宜超过 1000 行（MySQL 默认
max_allowed_packet限制，超了会报错Packets larger than max_allowed_packet are not allowed） - PostgreSQL 对单条
VALUES行数无硬限制，但过长会增加解析开销，建议单批 500–2000 行 - 避免拼接超长字符串构造 SQL——易出注入、内存溢出；应由应用层分批组装
大批量导入时该选 LOAD DATA INFILE 还是 COPY
当数据源是本地文件（如 CSV），LOAD DATA INFILE（MySQL）或 COPY（PostgreSQL）比任何 INSERT 都快一个数量级，因为它们绕过 SQL 解析层，直接加载到存储引擎。
使用前提与坑点：
- MySQL 的
LOAD DATA INFILE要求文件在数据库服务器本地（不是客户端），除非启用LOCAL INFILE并配置客户端和服务端都允许（local_infile=ON） - PostgreSQL 的
COPY默认只允许超级用户执行；普通用户需用COPY FROM STDIN配合客户端驱动（如 psycopg2 的copy_expert()） - 两者都不走触发器（
TRIGGER），也不校验外键（除非显式开启FOREIGN_KEY_CHECKS=1等），上线前务必确认业务逻辑是否依赖这些
ORM 场景下如何避免批量插入退化为 N+1
很多 ORM（如 Django ORM、SQLAlchemy）默认对 .bulk_create() 或 insertmany 提供封装，但行为差异大——不看文档很容易写出“假批量”。
典型问题：
- Django 的
Model.objects.bulk_create(...)若传入含id字段的实例，且数据库主键是自增，可能因未跳过id导致冲突或忽略 - SQLAlchemy 的
session.execute(insert(...).values([...]))是真批量；但误用session.add_all([...])+commit()仍是逐条 INSERT - 所有 ORM 的批量方法默认不返回插入后的主键（尤其是 PostgreSQL 的
RETURNING），需要显式指定才能拿到 ID 列表
性能影响明显：Django 在未设 batch_size 时，bulk_create 可能一次性塞 10 万行进单条 SQL，触发 MySQL 包大小限制而失败；建议始终指定 batch_size=1000。
真正容易被忽略的是：批量操作跳过模型层的 save() 方法，意味着 pre_save、post_save 信号、字段默认值计算、auto_now_add 等全不触发——必须提前在数据构造阶段补全。
