真正高效的MySQL批量插入应手写多值INSERT语句或启用executemany(..., multi=True)，默认executemany()实为单条循环，性能差5–10倍；需配合autocommit=False与手动commit，并注意SQL注入防护。
MySQL批量插入用executemany()还是INSERT ... VALUES (...), (...)？
直接结论：executemany()在默认配置下其实不真“批量”，它只是循环调用单条execute()；真正高效的批量插入得手写多值INSERT语句，或改用pymysql/mysql-connector-python的insertmany()（非标准）或executemany(..., args, multi=True)（需显式启用）。
常见错误现象是：爬虫吐出1万条数据，调用executemany("INSERT INTO t(x) VALUES (%s)", data)，结果入库耗时20秒以上——这基本等于1万次单条插入，网络往返和事务开销全摊进去了。
- 使用场景：单表写入、无触发器、主键/唯一键冲突可控（比如先
REPLACE或ON DUPLICATE KEY UPDATE） - 参数差异：
executemany()的args必须是序列的序列（如[(1,), (2,), (3,)]），而拼接多值INSERT时要注意SQL注入风险，必须用驱动原生占位符，不能字符串格式化 - 性能影响：手拼500行/批的
INSERT INTO t(x,y) VALUES (%s,%s),(%s,%s),...，比默认executemany()快5–10倍；再配合autocommit=False+ 手动commit()，还能再提一截
PostgreSQL里execute_batch()和copy_from()怎么选？
execute_batch()（来自psycopg2.extras）适合中小批量（≤1万行）、字段含JSON/数组等复杂类型；copy_from()更快但要求数据是纯文本流、列顺序严格匹配、不支持表达式或默认值计算。
容易踩的坑是：用copy_from()传入Python列表，报错AttributeError: 'list' object has no attribute 'read'——它要的是类文件对象，得先转成StringIO或用copy_expert()配VALUES子句。
立即学习“Python免费学习笔记（深入）”；
- 使用场景：
copy_from()适合原始结构化数据（如CSV解析后转元组列表），且表无自增主键依赖默认值；否则优先选execute_batch() - 兼容性影响：
copy_from()不走SQL解析器，绕过约束检查（除NOT NULL），上线前务必确认数据干净 - 示例片段：
execute_batch(cur, "INSERT INTO t(a,b) VALUES (%s, %s)", data, page_size=1000)，其中page_size控制每批提交量，设太大可能OOM
SQLite批量插入为什么加了PRAGMA synchronous = OFF还是慢？
因为没关journal_mode。默认DELETE模式每次事务都刷日志，即使关了synchronous，磁盘I/O仍在。真正提速得切到WAL或MEMORY模式，并配事务包裹。
典型错误是只改一个PRAGMA就以为万事大吉，结果10万行插入仍要十几秒——SQLite不是“设了就快”，而是“设对+用对”才快。
- 实操建议：建库后立即执行
PRAGMA journal_mode = WAL+PRAGMA synchronous = NORMAL（OFF有丢数据风险） - 必须把批量操作包在
BEGIN IMMEDIATE/COMMIT里，否则每个INSERT仍是独立事务 - 注意
WAL模式下，读操作可能看到旧快照，爬虫入库后立刻查总数，得加PRAGMA wal_checkpoint或等自动checkpoint
异步爬虫（aiohttp + asyncpg）入库时连接池不够用怎么办？
不是调大min_size/max_size就行。asyncpg连接池按协程调度，若爬虫并发200，但数据库最大连接数设成100，就会卡在acquire()等待，甚至触发超时断连。
更隐蔽的问题是：用async with pool.acquire()在每条记录上开连接，等于把异步池当同步池用，吞吐反而不如同步方案。
- 正确做法：批量攒够N条（比如500）再统一
execute_many()，连接复用率才能拉起来 - 参数差异：
min_size建议设为ceil(并发数 / 2)，max_size不超过数据库max_connections的70%，留余量给其他服务 - 性能陷阱：别在
for item in items:里逐条await conn.execute(...)，这是最慢写法；哪怕用gather()并发执行，也不如一次发500行
