MySQL ROW_COUNT 在普通 SELECT 后为什么返回负一

我第一次看到这个值时，也以为查询链路出了问题：普通 SELECT 执行成功，结果集也正常返回，紧接着调用 ROW_COUNT() 却得到 -1。这个值在 MySQL 里不是失败标记，而是在告诉你：上一条语句返回了结果集，当前函数没有把它当作“受影响行数”来统计。

先确认 -1 代表结果集而不是查询失败

ROW_COUNT() 的名字容易让人联想到“上一条 SQL 返回了多少行”。但 MySQL 对它的定义更接近“上一条语句影响了多少行”。普通 SELECT 的工作是向客户端交付结果集，并没有修改表中的行，因此返回 -1。

下面这组语句能说明边界。第二条 SELECT 只是读取上一条查询的执行结果状态，不会把第一条查询的结果集行数重新计算成正数。

-- 先产生结果集，再立即读取上一条语句的状态
SELECT id, order_no FROM orders WHERE status = 'paid';
SELECT ROW_COUNT();

-- 预期：ROW_COUNT() 为 -1，表示上一条 SELECT 返回了结果集

按语句类型区分 ROW_COUNT() 的统计口径

把语句类型分开后，这个值就不神秘了。DML（如 UPDATE、INSERT、DELETE）返回受影响行数；DDL（如 CREATE TABLE、DROP TABLE）返回 0；能返回结果集的普通 SELECT 返回 -1。特殊的 SELECT ... INTO OUTFILE 不返回给客户端，而是报告写入文件的行数。

需要统计查询行数时，改用 COUNT(*)

如果业务问题是“这次筛选命中了多少条订单”，目标是结果集大小，不是受影响行数。应让数据库明确计算行数：

-- 统计符合条件的行数，不依赖 ROW_COUNT() 的上一条语句语义
SELECT COUNT(*) AS total
FROM orders
WHERE status = 'paid';

-- 分页时把展示查询和总数查询分开，避免把 LIMIT 后的结果误当成总数
SELECT id, order_no
FROM orders
WHERE status = 'paid'
ORDER BY id DESC
LIMIT 20;

SELECT COUNT(*) AS total
FROM orders
WHERE status = 'paid';

分页总数和当前页条数是两个指标。若只想知道当前客户端收到多少条记录，由应用层读取结果集即可；不要把 ROW_COUNT() = -1 转换成零，也不要把它当作“没有命中数据”。

用会话边界排查误读和并发问题

我在应用排查中最容易忽略的点是“上一条语句”和“同一个连接”。ROW_COUNT() 应在目标 DML 后立即读取；中间插入一条查询、切换连接、交给连接池归还后再取值，都可能让代码读到别的语句状态。更新场景可以这样写：

-- 在同一连接中紧跟 UPDATE 读取受影响行数
UPDATE orders
SET status = 'shipped'
WHERE id = 1001 AND status = 'paid';
SELECT ROW_COUNT();

-- 这里的返回值表示实际改变的行数，不是 SELECT 结果集大小

落地前可以按这四项检查：第一，先写清楚要的是结果集行数还是写操作影响行数；第二，读取函数前不要插入其他 SQL；第三，连接池场景确认两条语句使用同一会话；第四，对“条件命中但值未改变”的 UPDATE 单独定义业务口径。默认配置下，MySQL 更偏向报告实际改变的行数，而不是仅匹配到的行数。

常见问题

普通 SELECT 返回 -1 是不是查询失败？

不是。只要结果集正常返回，-1 就是 MySQL 对该语句类型的规定值。

怎样得到 SELECT 真正返回了多少行？

需要总数时执行匹配条件一致的 COUNT(*)；需要当前页数量时由客户端统计实际收到的结果行。

UPDATE 匹配到一行但没有改值，ROW_COUNT() 是多少？

默认按实际改变的行数统计，因此可能是 0。如果客户端连接使用 CLIENT_FOUND_ROWS，受影响行口径会不同，应用应固定并记录该连接选项。