SQLAlchemy批量插入比循环execute快，因其复用预编译语句、合并参数、减少网络往返、SQL解析及事务日志刷盘次数；实测万级记录插入，前者耗时8–12秒，后者仅0.8–1.5秒，但依赖驱动是否原生支持批量协议。
SQLAlchemy批量插入为什么比循环execute快？
因为单次 execute() 触发一次网络往返 + 一次SQL解析 + 一次事务日志写入，而 executemany() 或 bulk_insert_mappings() 能复用预编译语句、合并参数、减少日志刷盘次数。实测插入1万条记录，前者耗时约8–12秒，后者通常压到0.8–1.5秒（PostgreSQL + 默认配置）。
但注意：这不是“自动加速”，而是依赖数据库驱动和后端是否真正支持批量协议。比如 MySQL 的 pymysql 对 executemany() 是模拟的（逐条发），而 mysqlclient 和 PostgreSQL 的 psycopg2 才是真批量。
- 确认驱动是否原生支持：查文档看是否标注 “supports server-side batch execution”
- 避免在事务外调用
executemany()—— 没有事务包裹时，每条仍可能隐式提交 - 数据量超5万条时，建议分批（如每5000条一 commit），防内存溢出或 WAL 日志撑爆
bulk_insert_mappings 和 insert().values() 怎么选？
两者都绕过 ORM 实例化开销，但语义和适用场景不同：
-
bulk_insert_mappings()：适合已有字典列表（如从 CSV/JSON 解析而来），不校验字段类型，不触发__init__或事件钩子，速度最快；但无法设置默认值或服务端生成字段（如server_default） -
insert(User).values([...])：走 Core 层，支持on_conflict_do_update()（PostgreSQL）、INSERT IGNORE（MySQL），能利用数据库原生 UPSERT 语义；但要求传入结构严格匹配表定义，且不支持嵌套对象
错误现象示例：bulk_insert_mappings(User, [{'name': 'Alice', 'age_str': '25'}]) 不报错，但 age_str 字段会被静默忽略 —— 因为模型里没这个属性。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
什么时候该用 session.bulk_save_objects()？
仅当你已有 ORM 实例、且需要保留部分 ORM 行为（如主键自增回填、关系对象状态跟踪）时才考虑它。它比 bulk_insert_mappings() 慢约20–40%，因为要走 ORM 映射层。
- 优点：插入后可直接访问
obj.id（对自增主键），适合后续立即关联其他对象 - 缺点：不跳过验证器（
@validates）、不跳过before_insert事件，容易因中间件逻辑拖慢速度 - 常见误用：拿它替代
bulk_insert_mappings()做纯数据导入 —— 完全没必要，白白承担 ORM 开销
如果你只是把 CSV 导进表，别碰 bulk_save_objects()；如果你在业务流中创建了一堆 User() 实例并准备统一落库，再考虑它。
批量操作后怎么安全获取插入ID？
SQLAlchemy 默认不返回批量结果（尤其是 executemany() 和 insert().values()），想拿 ID 必须显式要求。PostgreSQL 可用 returning()，MySQL 则基本无解（除非单条插入或用 lastrowid 配合自增）。
- PostgreSQL 示例：
stmt = insert(User).values(...).returning(User.id)，然后result.scalars().all() - MySQL 注意：
executemany()不支持RETURNING，lastrowid只返回第一条的 ID，不可靠 - 通用规避法：先用
SELECT nextval('seq_name')预取 ID 段，再批量插入时显式指定 —— 适合高并发 ID 分配场景
最容易被忽略的一点：哪怕用了 returning()，如果插入中途某条失败，整个语句会 rollback，你拿不到任何 ID —— 所以批量操作的原子性与结果可得性是互斥的，得按业务容忍度权衡。
