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 条件是否精准命中目标记录。