bulk_insert_mappings快是因为跳过orm实例化、不触发__init__/@validates/before_insert等钩子，直接编译字典为批量insert语句；但常因pymysql驱动模拟执行、未包事务、字段名不匹配或单批超5000条而失效。
bulk_insert_mappings 是最快的选择，但直接调用它不等于自动变快——多数性能问题出在驱动、事务或字段匹配上。
为什么 bulk_insert_mappings 有时慢得像没用？
它快，是因为跳过 ORM 实例化、不走 __init__、不触发 @validates 或 before_insert，直接把字典编译成批量 INSERT 语句。但“没变快”往往因为：
-
pymysql驱动对executemany()是 Python 层模拟（逐条发），不是真批量；换成mysqlclient或psycopg2才生效 - 没包在事务里：
bulk_insert_mappings自身不开启事务，若连接是 autocommit 模式，每批仍被隐式提交 - 字段名不匹配：传
{'age_str': '25'}，模型只有age，该字段静默丢弃，无报错也无警告 - 单次传入超 5000 条：可能触发 PostgreSQL 参数绑定限制，或 MySQL 的
max_allowed_packet
bulk_insert_mappings 和 insert().values() 怎么选？
两者都绕过 ORM 实例化，但底层不同、适用场景明确：
-
bulk_insert_mappings(User, data)：纯 ORM 接口，只认模型定义字段，不校验类型，不支持on_conflict_do_update或INSERT IGNORE；适合从 CSV/JSON 解析的字典，且字段完全匹配模型 -
session.execute(insert(User).values(data))：走 Core 层，支持数据库原生冲突处理（如 PostgreSQL 的on_conflict_do_update）、server_default字段自动填充、严格结构校验 - 如果你要写入时自动补
created_at（设了server_default），必须用后者；如果只是导入干净字典，前者更轻量
分批提交多少条才合理？
不分批易撑爆内存或 WAL 日志（尤其 PostgreSQL），但批太小又失去批量意义：
- 每批 1000–5000 条较稳妥：兼顾内存压力与网络吞吐，避免单条 SQL 过长
- 用生成器分 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 或关联其他对象的场景。但以下属于典型误用：
- 从 CSV 解析后手动构造
User(name=...)再喂给bulk_save_objects—— 完全没必要，白白承担 ORM 开销 - 想靠它跳过验证逻辑：它仍会触发
@validates和before_insert，速度比bulk_insert_mappings慢 20–40% - 你只是把数据灌进表，不需要对象状态跟踪，就别碰它
真正容易被忽略的是驱动层是否原生支持批量协议——查文档确认是否标注 “supports server-side batch execution”，而不是默认它一定快。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
