mysqli_query()执行成功但数据库未变，主因是事务未提交、SQL未匹配记录或字符集不一致；应检查mysqli_affected_rows()、统一utf8mb4编码、避免拼接SQL、核对预处理参数类型。
mysqli_query() 执行成功但数据库没变
这通常不是连接问题，而是事务未提交、SQL 语句本身没生效，或执行了却没检查返回值。重点排查：mysqli_query() 返回 true 只代表语句被 MySQL 接收并解析通过，并不等于“数据真的改了”。比如 UPDATE 匹配 0 行时也返回 true。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 立刻在
mysqli_query()后加var_dump(mysqli_affected_rows($link));—— 若输出0，说明 SQL 没命中任何记录，检查WHERE条件、字段名、引号类型（单引号 vs 双引号）、空格/大小写敏感性 - 确认是否开启了事务：若用了
mysqli_begin_transaction($link)或手动执行了START TRANSACTION，必须显式调用mysqli_commit($link)，否则所有变更在连接关闭时自动回滚 - 避免在 SQL 中混用变量拼接和预处理：例如
"UPDATE t SET x = '$val' WHERE id = $id"容易因$val含单引号或为空导致语法错误，MySQL 可能静默忽略整条语句
预处理语句 bind_param() 后 execute() 没报错但更新失败
常见于参数类型绑定错误，比如把字符串用 i（integer）传入，或把 NULL 当成字符串传 —— MySQL 会尝试隐式转换，转换失败时可能设为默认值（如 0 或空字符串），而非报错。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 严格核对
bind_param()第一个参数的类型字符：数字用i，字符串用s，大文本用s（不是b，除非真要传 blob），NULL 用i+ 值为null，且确保变量本身是null而非"null"字符串 - 执行
execute()后立刻检查$stmt->affected_rows，不要只看$stmt->execute()返回值（它只表示执行是否成功，不反映影响行数） - 调试时临时把预处理转为普通查询：用
$stmt->debugDumpParams()查看实际绑定的值和类型，或用$stmt->get_warnings()捕获隐式转换警告
PHP 连上数据库但 UPDATE 语句在 phpMyAdmin 里能跑，PHP 里不行
大概率是字符集不一致导致 WHERE 条件匹配失败。例如 PHP 连接时用 utf8mb4，但表字段是 latin1，或者 PHP 文件保存为 GBK 编码而 SQL 里写了中文条件。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 统一强制设置连接字符集：执行
mysqli_set_charset($link, 'utf8mb4')（不能只靠配置文件或SET NAMES） - 检查字段实际编码：
SHOW CREATE TABLE your_table看对应字段的CHARACTER SET和COLLATION，确保与连接一致 - 用
bin2hex($str)对比 PHP 中的条件值和数据库里查出的原始字节，确认是否发生编码截断或乱码（比如中文变成??或长度异常）
更新语句带 LIMIT 1 却始终不生效
LIMIT 在 UPDATE 中是 MySQL 特有语法，但 PHP 的 mysqli/pdo 默认不报错，尤其当驱动版本低或模式宽松时，会直接忽略 LIMIT 并执行无限制更新 —— 或者反过来，因语法不识别而静默失败。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先确认 MySQL 版本是否 ≥ 4.0（
LIMITforUPDATE自此支持），再查当前连接的 SQL mode 是否含STRICT_TRANS_TABLES；若不含，MySQL 可能吞掉语法错误 - 换用子查询方式替代
LIMIT：例如UPDATE t SET x=1 WHERE id IN (SELECT id FROM (SELECT id FROM t ORDER BY id LIMIT 1) AS tmp) - 最稳妥做法：先
SELECT出目标 ID，再用该 ID 做UPDATE，逻辑清晰且可 debug 中间结果
真正卡住的时候，往往不是连不上，而是“以为连上了、以为执行了、以为改成功了”——盯住 affected_rows，抓到真实影响行数，比反复检查连接字符串有用得多。
