PHP执行UPDATE需用mysqli或PDO预处理语句，必须带WHERE条件，通过affected_rows或rowCount检查实际影响行数，并注意字符集、SQL模式与事务提交。
PHP 中执行 UPDATE 语句的基本写法
PHP 本身不直接“更新数据”，而是通过数据库扩展（如 mysqli 或 PDO）向 MySQL 等数据库发送 UPDATE SQL 语句。最安全、推荐的方式是使用预处理语句，避免 SQL 注入。
关键点：必须带 WHERE 条件，否则整张表所有记录都会被修改。
-
mysqli面向对象风格示例：
$mysqli = new mysqli("localhost", "user", "pass", "db");
$stmt = $mysqli->prepare("UPDATE users SET name = ?, email = ? WHERE id = ?");
$stmt->bind_param("ssi", $new_name, $new_email, $id);
$new_name = "Alice";
$new_email = "alice@example.com";
$id = 123;
$stmt->execute();-
PDO预处理示例：
$pdo = new PDO("mysql:host=localhost;dbname=db", "user", "pass");
$stmt = $pdo->prepare("UPDATE users SET status = :status WHERE id = :id");
$stmt->execute(["status" => "active", "id" => 456]);为什么不能直接拼接字符串执行 UPDATE
用 "UPDATE users SET name = '" . $_POST['name'] . "' WHERE id = " . $_GET['id'] 这类拼接方式极危险。一旦用户输入包含单引号或 SQL 片段（如 ' OR 1=1 -- ），就可能触发全表更新、删库甚至拖库。
- 常见错误现象：
mysqli_query()返回true，但实际改了 0 行或全部行，日志里查不到明确报错 -
mysql_*函数已彻底废弃（PHP 7.0+ 移除），不能再用 - 即使加了
mysqli_real_escape_string()，也无法完全防御多字节编码绕过或边界场景
UPDATE 执行后怎么确认是否成功修改了数据
不能只看 execute() 或 query() 是否返回 true——它只表示 SQL 语法正确、连接正常，并不反映是否有匹配记录被更新。
-
mysqli_stmt::affected_rows返回实际被修改的行数（注意：若新旧值相同，MySQL 默认返回 0） -
PDOStatement::rowCount()同理，返回匹配并变更的行数 - 需要结合业务逻辑判断：比如期望改 1 行，结果
rowCount() === 0，可能是WHERE条件没命中，也可能是原值本就一样
示例检查逻辑：
$stmt->execute();
if ($stmt->rowCount() === 0) {
echo "未找到匹配的记录，或数据未发生实际变更";
}UPDATE 操作中容易忽略的细节
很多问题不是语法错，而是隐含
行为导致的“看似没更新”：
- MySQL 的
sql_mode包含STRICT_TRANS_TABLES时，对空字符串插入非空字段会报错；不启用时可能静默截断或转为默认值 - 时间字段（如
DATETIME）传入非法格式（"2025-02-30"）在宽松模式下会变成"0000-00-00"，但不会报错 - 字符集不一致：PHP 文件是 UTF-8，但数据库连接未设
SET NAMES utf8mb4，中文可能存成乱码或被截断 - 事务未提交：
PDO默认自动提交，但若手动调用了beginTransaction()，忘记commit()就等于没改
建议在连接建立后立即设置：
$mysqli->set_charset("utf8mb4");
// 或 PDO DSN 加上 charset：
$pdo = new PDO("mysql:host=localhost;dbname=db;charset=utf8mb4", ...);UPDATE 不是黑盒操作，每一步的返回值、影响行数、字符集和 SQL 模式都得盯住。尤其上线前用真实数据测一遍 WHERE 条件是否精准命中目标记录。
