postgresql 中 insert().on_conflict_do_update() 不返回行数，需用 RETURNING 子句配合 fetchall() 计数；mysql 依赖 rowcount（需 exec_driver_sql）；sqlite 用 changes()；ORM 中避免 merge()，应使用 returning()。
SQLAlchemy 里 insert().on_conflict_do_update() 不返回行数
PostgreSQL 的 ON CONFLICT DO UPDATE 本身不直接返回“影响了多少行”，execute() 返回的 Result 对象默认也不暴露这个信息。你调用 result.rowcount 得到的往往是 -1（尤其在 psycopg2 异步或某些驱动配置下），不是真实受影响行数。
真正能拿到插入/更新行数的方式，是靠 RETURNING 子句 + 手动计数：
- 对 PostgreSQL：用
INSERT ... ON CONFLICT DO UPDATE RETURNING id，然后统计result.fetchall()长度 - 对 MySQL：原生不支持
ON DUPLICATE KEY UPDATE的RETURNING，得靠rowcount—— 但必须确保使用exec_driver_sql()或显式设置cursor.rowcount可用（如关闭连接池预处理） - 对 SQLite：
INSERT OR REPLACE后查connection.execute("select changes()").scalar()
PostgreSQL 实操：用 RETURNING 精确统计
这是最可靠的方式，适用于需要区分“新插入”和“已存在但更新”的场景：
from sqlalchemy import text stmt = text(""" INSERT INTO users (id, name, email) VALUES (:id, :name, :email) ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name, email = EXCLUDED.email RETURNING id """) result = conn.execute(stmt, {"id": 123, "name": "Alice", "email": "a@b.com"}) affected_count = len(result.fetchall()) # ✅ 真实行数
注意点：
-
RETURNING必须指定至少一个列（哪怕只写RETURNING 1），否则fetchall()为空，长度为 0 - 不能混用 ORM 模型对象直接传入
text()；要用原生参数绑定 - 如果想同时知道是 insert 还是 update，可在
RETURNING里加伪列：RETURNING CASE WHEN xmax = 0 THEN 'insert' ELSE 'update' END（PostgreSQL 内部机制）
MySQL / SQLite 的兼容性取舍
MySQL 的 ON DUPLICATE KEY UPDATE 会把“插入”和“更新”都算作“受影响行数”，但 SQLAlchemy 默认不透出这个值：
- 用
exec_driver_sql()（SQLAlchemy 2.0+）可绕过 ORM 层限制：result = conn.exec_driver_sql("INSERT INTO t ... ON DUPLICATE KEY UPDATE ...")，之后result.rowcount通常可用 - SQLite 的
INSERT OR REPLACE本质是删+插，rowcount不稳定；推荐改用conn.exec_driver_sql("SELECT changes()").scalar()获取最后操作变更行数 - 跨数据库抽象时，别依赖
rowcount—— 它在不同方言、不同执行模式（如 execute vs executemany）下行为差异极大
ORM 层怎么写？别用 merge()
session.merge() 看似符合“插入或更新”语义，但它内部是先 SELECT 再决定 insert/update，无法原子化，且 rowcount 总是 1（不管实际是否写入）。
真要走 ORM 路线，只能手动控制：
- 用
session.execute(insert(...).on_conflict_do_update(...).returning(...))（SQLAlchemy 2.0+ 支持） - 避免混合 ORM 实例和原生语句；一旦用了
RETURNING，就老实用字典或元组接收结果 - 别指望
session.commit()后从 session 缓存里反推影响行数——缓存不记录底层 DML 统计
最易被忽略的是：RETURNING 在 PostgreSQL 中要求目标表有主键或唯一约束才能触发 ON CONFLICT，否则语法报错；而 MySQL 的 ON DUPLICATE KEY UPDATE 则强制依赖已有 UNIQUE/PRIMARY KEY 索引 —— 约束缺失时，所谓“插入或更新”会静默变成纯插入，且无提示。