php mysqli_num_rows 行数统计：别拿它硬扛大数据量

写后台管理功能时，验证书单是否存在或是核对导入结果，几乎是每个 PHP 开发者都会碰到的日常场景。很多人习惯直接跑一次查询，顺手甩出 mysqli_num_rows($result) 看返回了多少行。这函数本身没毛病，但用错了调用时机，轻则拖垮服务器内存，重则让业务校验频频翻车。

得先摸清它的职责边界。mysqli_num_rows 只认查询语句（SELECT），它统计的是已构建好的结果集里的记录条数。如果你刚执行完 INSERT 或 UPDATE，指望它告诉你影响了几条数据，拿到的多半是 0 或布尔假值。这类改动型操作该交给 mysqli_affected_rows。数据库连接在每次执行完特定指令后都会刷新内部状态，张冠李戴的用法在排查性能瓶颈时，往往是最先被揪出的隐形地雷。

遇到数据量不大的表，直接拉全量再清点数量确实省心。可一旦业务表积累了几万条以上记录，把整批数据塞进 PHP 变量阵列再数人头，就是典型的内存透支行为。请求延迟陡增不说，Web 服务器的临时空间也会被迅速占满。更稳妥的做法是提前收敛范围：*用 `SELECT COUNT() FROM table WHERE conditions` 替代全量提取**。数据库引擎会在存储引擎层走统计索引，执行时间从几百毫秒压到个位数毫秒，PHP 端也彻底省下了反序列化海量数据的力气。

实际落地时，做防重校验或状态比对，代码结构可以收得更紧凑。配合预处理语句能直接把注入风险拦在外围。

$stmt = $mysqli->prepare("SELECT id FROM accounts WHERE phone = ? LIMIT 1");
$stmt->bind_param("s", $input_phone);
$stmt->execute();
$stmt->store_result();

// **关键动作：预处理对象必须显式缓存结果集，否则 num_rows 可能返回异常值**
if ($stmt->num_rows === 1) {
    echo "号码已占用";
}

这段写法藏着一个经常被教程略过的细节：MySQLi 的预处理默认采用流式返回。如果不主动触发 store_result()，底层还没把完整结果打包成数组，此时读 num_rows 会得到不可控的数值。补上这一行，逻辑链条才算真正闭合。

有些老项目习惯把 num_rows > 0 当作唯一的存在性判定标准。其实在 PHP 7+ 环境下，直接尝试取第一条关联数组更利落。例如 $row = $stmt->fetch_assoc() 成功吐出键值对，说明库里有货；返回 null 则代表空集。这种写法跳过了多余的计数步骤，代码意图也更直白。

工具的价值永远取决于使用场景。mysqli_num_rows 适合处理已经加载到内存的小型结果集复核；面对高并发查询或长尾数据盘点，养成随手切到 COUNT(*) 的习惯，能让系统保持轻盈。理清底层调用链路，比死记硬背 API 参数更能少走弯路。