mysqli_num_rows返回结果集行数，仅适用于select等查询；对insert/update/delete返回0；若未缓冲结果集或未调用mysqli_store_result()，即使有数据也返回0。
mysqli_num_rows 返回的是一个整数，表示结果集中包含的行数——但仅当查询是 SELECT、SHOW、DESCRIBE 或 EXPLAIN 这类返回结果集的语句时才有效；对 INSERT、UPDATE、DELETE 等语句，它返回 0，哪怕你误用了它。
为什么 mysqli_num_rows 有时返回 0，明明查到了数据？
最常见原因是：没调用 mysqli_store_result() 或没走完整结果获取流程。在使用 mysqli_query() 后，如果直接对返回的 mysqli_result 对象调用 mysqli_num_rows()，看起来没问题，但前提是这个结果集必须是“缓冲”的（buffered）。
而如果你用的是 mysqli_use_result()，或者启用了无缓冲查询（比如设置了 MYSQLI_STORE_RESULT 以外的选项），结果集不会被一次性读入内存，mysqli_num_rows() 就无法预知总行数，只能返回 0。
- 默认情况下
mysqli_query()是缓冲查询，mysqli_num_rows()可用 - 但若手动调用
mysqli_use_result()，就必须先遍历完结果，或改用mysqli_fetch_all()再取count() - 注意：pdo 的
rowCount()在 SELECT 上行为不同（多数驱动不支持，返回 -1），别混用
mysqli_num_rows 和 mysqli_affected_rows 到底该用哪个？
这是新手最容易混淆的一对函数。它们根本不是替代关系，而是服务完全不同的场景：
-
mysqli_num_rows()只用于SELECT类查询，告诉你“查出来多少行” -
mysqli_affected_rows()用于INSERT/UPDATE/DELETE，告诉你“影响了多少行”（包括被更新但值没变的行） - 对
SELECT调用mysqli_affected_rows()，返回值是 -1（表示不适用） - 对无变化的
UPDATE（比如SET name='a' WHERE name='a'），mysqli_affected_rows()可能返回 0 —— 这是正常行为，不代表出错
性能和兼容性：什么时候不该依赖 mysqli_num_rows？
当结果集很大时，mysqli_num_rows() 虽然只是读一个内部计数器，但前提是结果集已缓冲。如果用 mysqli_query() 获取了大结果却没消费，会占用大量内存；更糟的是，有些托管环境限制了单次查询内存，可能直接报 Out of memory 错误。
- 只查总数？直接写
SELECT COUNT(*) FROM ...，比SELECT *+mysqli_num_rows()快得多也省资源 - 需要分页且数据量大？避免先查全量再用
mysqli_num_rows()算总页数，改用SQL_CALC_FOUND_ROWS（已弃用）或两次查询（COUNT(*)+LIMIT） - PHP 8.1+ 中，
mysqli_result对象的num_rows属性（如$result->num_rows）和函数等价，但属性访问稍快，且更符合现代写法
真正容易被忽略的是：它不校验数据有效性，也不感知 SQL 注入或权限问题——返回 5 行，不代表这 5 行都该给你看；返回 0，也不代表没数据，可能只是查询失败后你没检查 mysqli_error() 就直接用了结果对象。