单条INSERT循环写入慢，因每次执行都触发网络往返或日志刷盘，并伴随SQL解析等开销；推荐用executemany()批量插入，注意参数格式与分批大小，大批量时优先使用COPY/LOAD DATA等原生导入方式。
为什么单条 INSERT 循环写入慢得明显？
因为每次 cursor.execute() 都会触发一次网络往返（远程数据库）或事务日志刷盘（本地 SQLite/PostgreSQL），还附带 SQL 解析、权限检查等开销。1000 条记录逐条插入，可能比批量插入慢 5–20 倍，具体取决于数据库类型和网络延迟。
常见错误现象：OperationalError: database is locked（SQLite）、TimeoutError（MySQL/PostgreSQL）、CPU 或 I/O 在循环中持续飙高但吞吐上不去。
- 别用
for row in data: cursor.execute("INSERT ...", row)处理超过 100 行的数据 - 确认数据库是否启用了自动提交（
autocommit=False是默认且推荐的，否则每条语句都隐式提交，更慢） - 避免在循环内反复调用
connection.commit()—— 这等于把“批量”又拆回了“单条”
executemany() 是最直接的替代方案，但要注意参数格式
executemany() 本质是让驱动层把多组参数一次性拼成底层支持的批量协议（如 PostgreSQL 的 INSERT ... VALUES (...), (...)，MySQL 的多值 INSERT）。它不改变 SQL 字符串结构，只替换 %s 或 ? 占位符。
关键限制：所有参数必须是长度一致的序列（list 或 tuple），且每项必须是可迭代的“一行值”。常见踩坑点：
立即学习“Python免费学习笔记（深入）”；
- 传入
[[1, "a"], [2, "b"]]✅；传入[(1, "a"), (2, "b")]✅；但传入[1, "a", 2, "b"]❌（会被当成 1 行 4 列） - SQLite 支持
executemany()，但默认有 999 参数上限（可通过PRAGMA limit调整，或分批） - MySQLdb / PyMySQL 对超大参数列表可能报
PacketTooLarge，需控制每批 ≤ 1000 行
示例：
cursor.executemany(
"INSERT INTO users (id, name, email) VALUES (?, ?, ?)",
[(1, "Alice", "a@x.com"), (2, "Bob", "b@x.com")]
)
大批量场景下，用原生批量导入（如 COPY、LOAD DATA）跳过 SQL 解析层
当单次写入 > 10k 行，且数据已存在本地（如 CSV、内存 list），绕过 Python 驱动的 SQL 构建环节，直连数据库的批量通道，性能提升常达 5–10 倍。
各数据库差异明显：
- PostgreSQL：优先用
cursor.copy_from()（配合StringIO或文件）或copy_expert()执行COPY命令 - MySQL：用
cursor.execute("LOAD DATA INFILE ...")（注意secure_file_priv限制）或pymysql的executemany()+ 分批（更可控） - SQLite：用
connection.executescript()拼接多条INSERT（仅限小数据），或导出为 CSV 后用.import命令（CLI 场景）
注意：COPY 和 LOAD DATA 不走常规事务日志路径，部分数据库不支持回滚，也绕过触发器和外键检查（需提前确认业务约束是否允许）。
分批大小不是越大越好，要平衡内存、锁时间和错误恢复成本
设每批 1000 行看似合理，但实际要结合数据库配置、行宽、网络稳定性动态调整。例如：平均行宽 2KB，1000 行 ≈ 2MB 内存暂存；若网络抖动导致某批失败，重试成本就是 2MB 数据重传。
- 建议起始值：SQLite 用 500，PostgreSQL 用 1000–5000，MySQL 用 500–2000
- 在循环中显式控制批处理，而非依赖
executemany()自动切分（它不会自动分批） - 加
try/except包裹每一批，并记录失败批次的起始索引，便于断点续传 - 避免在事务中塞入过大批次 —— 可能导致 WAL 文件暴涨（PostgreSQL）或锁表时间过长（MySQL InnoDB）
真正影响最终性能的，往往不是“用不用批量”，而是“批多大”“在哪切”“失败后怎么兜住”。这些细节在压测时才会暴露，别只看文档给的推荐值。
