PHP带token验证的UPDATE执行后，数据库已更新却显示错误提示

• 对mysqli_num_rows()的适用场景存在本质误解：该函数仅能对SELECT、SHOW、DESCRIBE等返回结构化结果集的查询生效，UPDATE、INSERT、DELETE这类写操作执行后不会生成可遍历的结果集，对这类语句调用mysqli_num_rows()完全无法获取有效计数，必然触发判断逻辑的else分支。
• 换用mysqli_affected_rows()时存在规则认知偏差：该函数统计的是实际发生字段值变更的行数量，并非满足WHERE匹配条件的行数量。按照MySQL的默认执行逻辑，只要UPDATE语句匹配到的行，SET后的新字段值和原有值完全一致，就不会触发实际的数据修改，对应的影响行计数会返回0。此时哪怕SQL执行正常、用户邮箱和token的验证完全匹配，只要新密码的MD5值和数据库中存储的旧值没有差异，就会被误判为执行失败。
• 存在操作顺序不当的潜在问题：如果执行完UPDATE语句后，调用mysqli_affected_rows()之前插入了其他数据库操作，函数会返回最后一次数据库交互的影响行数，和目标UPDATE的执行结果完全不对应，同样会造成判断偏差。

• 彻底移除对mysqli_num_rows()的判断逻辑，所有数据库写操作的结果校验不能使用该函数。
• 正确调整mysqli_affected_rows()的使用方式与判断逻辑：
  • 调用时机必须紧跟UPDATE语句的mysqli_query()执行动作，中间不要插入任何其他数据库操作，保证获取的是目标语句的真实执行结果。
  • 不要将“影响行数大于0”作为唯一的成功判断标准：只要函数返回值不等于-1（即SQL执行过程没有报错），就代表整个业务流程逻辑通顺——这种场景下哪怕用户输入的新密码和原密码完全一致，只要通过了邮箱和token校验，就应该正常跳转至登录页，无需判定为错误。只有当返回值为-1时，才代表SQL执行异常，进入错误提示分支。
• 附加优化：当前代码采用直接拼接SQL变量的写法存在SQL注入风险，建议改用mysqli预处理语句绑定参数，替代字符串拼接的SQL构造方式。

内容的提问来源于stack exchange，提问作者SAW Kk