bulk_insert_mappings快是因为跳过ORM实例化、不触发__init__/@validates/before_insert等钩子，直接将字典编译为批量INSERT语句；不生效常见于驱动不支持原生批量（如pymysql模拟执行）、未包在事务中、字段名不匹配导致静默忽略。
bulk_insert_mappings 为什么快，但有时又不生效？
它快，是因为跳过 ORM 实例化、不触发 __init__、@validates、before_insert 等钩子，直接把字典列表编译成批量 INSERT 语句发给数据库。但“不生效”常发生在以下情况：
- 驱动不原生支持批量协议：比如
pymysql的executemany()是 Python 层模拟的（逐条发），而psycopg2（PostgreSQL）和mysqlclient才是真批量；查驱动文档确认是否标注supports server-side batch execution - 没包在事务里：
bulk_insert_mappings本身不开启事务，若连接处于 autocommit 模式，每批仍可能被隐式提交——务必用session.begin()或显式session.commit() - 字段名对不上：传入字典含
age_str，但模型里只有age，该字段会被静默忽略，无报错也无警告
insert().values() 和 bulk_insert_mappings 怎么选？
两者都绕过 ORM 实例，但底层走的不是同一层：
-
bulk_insert_mappings(User, data)：纯 ORM 接口，只认模型定义的字段，不校验类型，不支持on_conflict_do_update或INSERT IGNORE -
session.execute(insert(User).values(data))：走 Core 层，支持数据库原生冲突处理（如 PostgreSQL 的on_conflict_do_update）、字段默认值（server_default）、严格结构校验 - 如果数据来自 CSV/JSON 字典且字段完全匹配模型，优先用
bulk_insert_mappings；如果要 upsert 或依赖服务端默认值，必须用insert().values()
数据量超 5 万时，分批提交怎么设才合理？
不分批容易撑爆内存或 WAL 日志（尤其 PostgreSQL），但批太小又失去批量意义。实测建议：
- 每批 1000–5000 条较稳妥：兼顾内存压力与网络吞吐，避免单次语句过长触发数据库限制
- 用生成器分 chunk，别一次性加载全部数据到内存：
data_iter = (dict(...) for i in range(n)) - 每次
session.bulk_insert_mappings()后立即session.commit()，不要攒到最后——否则失败时回滚代价巨大 - PostgreSQL 用户可临时调大
max_wal_size，MySQL 用户调高innodb_buffer_pool_size，能进一步释放写入瓶颈
什么时候绝对不该用 bulk_save_objects？
它适合已有 ORM 实例、且后续立刻要读取 obj.id 或关联其他对象的场景。但以下情况属于典型误用：
立即学习“Python免费学习笔记（深入）”；
- 从 CSV 解析后手动构造
User(name=..., email=...)再喂给bulk_save_objects——白白承担实例化开销，比bulk_insert_mappings慢 20–40% - 导入日志、埋点等纯流水数据，不需要 ORM 状态跟踪，却选它——触发验证器、事件钩子，反而拖慢速度
- 数据量大但不关心主键回填（如 UUID 主键），还坚持用它——完全没必要，
bulk_insert_mappings或insert().values()更干净
真正需要 bulk_save_objects 的时刻很少：仅当你已有一堆带业务逻辑的 User() 实例，且下一行代码就要调用 user.posts.append(...) 这类关系操作时，才值得多花那点性能代价。
