mysql中delete后应立即调用row_count()获取实际删除行数，它返回匹配并删除的行数而非扫描行数；postgresql需用returning子句或with...select count(*)统计；python驱动中cursor.rowcount可用但行为不一。
MySQL里DELETE后怎么看影响行数
执行 DELETE 后，MySQL 本身不会自动输出影响行数，得靠客户端或语句主动获取。最直接的方式是用 ROW_COUNT() 函数——它返回上一条 DML（INSERT/UPDATE/DELETE）实际变更的行数。
- 必须在
DELETE执行完后**立刻**调用ROW_COUNT()，中间不能夹杂其他语句（哪怕只是SELECT 1），否则值会被覆盖 - 在命令行客户端（mysql CLI）里，执行
DELETE后会直接显示类似Query OK, 42 rows affected，这个数字就是真实影响行数，但脚本里不可靠，不能依赖它做逻辑判断 -
ROW_COUNT()返回的是**匹配并删除的行数**，不是 WHERE 条件扫描的行数；如果 WHERE 没命中任何行，返回 0
PostgreSQL怎么查DELETE影响了多少行
PostgreSQL 不提供类似 ROW_COUNT() 的函数，而是靠 RETURNING 子句或客户端反馈。最稳妥的方式是加 RETURNING * 或 RETURNING COUNT(*)（但注意：后者不合法，得靠外部统计）。
- 用
DELETE ... RETURNING id可以拿到所有被删行的主键，再在应用层统计长度——适合小到中等数据量，且你需要确认删了哪些具体记录 - 如果只关心数量，推荐用
WITH deleted AS (DELETE ... RETURNING 1) SELECT COUNT(*) FROM deleted，这样一次查询就能得到准确数字 - psql 命令行执行后会显示
DELETE 42，但程序里不能解析 stdout，必须用上述 SQL 方式获取 - 注意：如果 DELETE 被触发器拦截或改写（比如转成 UPDATE），
RETURNING仍只反映 DELETE 语句本身“声称”删掉的行，不是最终物理删除数
Python里用DB-API获取DELETE影响行数
几乎所有 Python 数据库驱动（mysql-connector-python、pymysql、psycopg2）都支持 cursor.rowcount 属性，但它行为不一致，容易踩坑。
-
mysql-connector-python和pymysql的cursor.rowcount在execute("DELETE ...")后立即可用，值等于 MySQL 的ROW_COUNT() -
psycopg2的cursor.rowcount在DELETE后也有效，但仅当语句含RETURNING时才准确；否则可能返回 -1（未实现）或预估值 - 安全做法：对 PostgreSQL，坚持用
WITH ... SELECT COUNT(*)包裹；对 MySQL，用cursor.rowcount即可，但别在commit()后读它——事务提交不影响该值，但后续语句会覆盖 - 别信
cursor.execute("SELECT ROW_COUNT()")这种写法——在 psycopg2 里会报错，因为 PostgreSQL 没这函数
为什么WHERE条件没生效却显示“0 rows affected”
看起来像没删成，其实是正常现象。关键是分清“语法执行成功”和“逻辑匹配成功”。
- 只要 SQL 语法正确、权限足够、表存在，
DELETE就算执行成功，哪怕WHERE条件一个都不匹配——此时影响行数就是 0 - 常见误导场景：条件字段类型不匹配（比如用字符串比较数字字段：
WHERE id = '123'而id是BIGINT），MySQL 可能隐式转换失败，PostgreSQL 直接报错，结果都是 0 行 - 时间字段要注意时区：用
WHERE created_at > '2024-01-01'在 UTC 时区连接下，可能因服务器时区不同导致预期外的 0 行 - 检查是否误用了
IN空列表（WHERE id IN ()）——MySQL 允许但返回 0，PostgreSQL 直接语法错误
rowcount == 0 很可能意味着 WHERE 条件写错了，或者数据状态已变。
