数据到底改没改？MySQLi 里 mysqli_affected_rows 的实战与避坑

写 PHP 操作数据库时，很多人习惯把 $mysqli->query($sql) 或预处理对象的 execute() 返回的布尔值当作唯一标准。只要不为 false，就默认流程走通。实际维护老项目或写定时任务时却常踩坑：代码运行平稳，业务逻辑照常推进，回头一核对表，数据纹丝不动。症结往往在于忽略了那条沉默的指标——mysqli_affected_rows。它不替你背锅 SQL 语法错误，只负责汇报一次增删改操作后，存储引擎真正落盘的数据行数。

新手最容易拿它和 num_rows 混为一谈。num_rows 盯着 SELECT 捞上来的结果集，而 mysqli_affected_rows 专门丈量 INSERT、UPDATE、DELETE 的改动幅度。比如一条 UPDATE 语句命中了五十条记录，但新传进去的值和库里原本的完全一致，InnoDB 会优化掉冗余写入，此时该函数会干净利落地返回 0。这个看似反直觉的行为，恰恰是定位“假更新”最快的探针。

把握调用时机是第一条铁律。 该函数的数值严格绑定上一条执行的 DML 语句，一旦你在中间穿插一条 SELECT 或者顺手打印个调试信息，返回值立刻归零。验证逻辑必须紧跟在执行语句的下一行写完，别给数据库留插话的机会。同时要注意，它统计的是物理变更量，而非条件命中量。遇上 INSERT IGNORE 遇到重复主键被静默丢弃，或者 DELETE 的 WHERE 条件根本没筛中任何数据，它只会如实返回 0。理解这层映射关系，能砍掉大半关于“返回值不准”的内部摩擦。

落到具体业务里，这条函数能撑起一套完整的变更校验链路。以异步任务同步商户营业状态为例，单纯依赖布尔返回值根本无法区分“执行失败”和“无差异”，容易导致队列死循环重试。我们可以把判断重心平移过来：

$stmt = $mysqli->prepare("UPDATE merchants SET status = ? WHERE merchant_id = ?");
$stmt->bind_param("si", $new_status, $id);
$stmt->execute();

$changed = $mysqli->affected_rows;
if ($changed > 0) {
    // 确有字段变动，清理关联缓存并下发站内信
    cache::forget("merchant:$id");
} else {
    // 语句无误但无实际写入，记录追踪 ID 避免盲目告警
    logger::notice("状态同步完成，当前数据已处于预期态", ['merchant_id' => $id]);
}

把 > 0 和 === 0 拆成两条明确的路径，代码的防御性会明显提升。尤其在消息队列消费端或 cron 脚本里，准确识别零变更状态，既能切断无效网络请求，又能让监控大盘的报警阈值更贴近真实风险。

往架构层面延伸，mysqli_affected_rows 还能充当轻量级乐观锁的标尺。并发高峰期直接上行锁会影响吞吐量，我们可以在表结构里预留一个 version 字段，更新时带着版本条件一起拼入 SQL。执行完毕后立刻抓取影响行数，若结果为 0，说明同期有另一笔请求抢先提交了新版本。此时不需要抛出致命异常中断交易流，只需按业务预案走降级读取或提示前端稍后重试即可。这种基于影响行数的博弈策略，兼顾了系统鲁棒性与响应速度。

数据库交互从来不是“抛出去就算完结”。mysqli_affected_rows 像一块校准仪，把模糊的执行反馈还原成可量化的变动刻度。摸清它的脾气，卡准调用节点，配合清晰的条件分支，数据层的掌控力会扎实不少。下次敲下增删改语句时，顺手带上它看一眼，少些猜测，多些底气。