批量更新应优先用case when实现原子性操作，其次考虑insert...on duplicate key update，复杂逻辑则用php循环加事务控制，关键在where精确性和参数化防注入。
UPDATE 语句里用 CASE WHEN 批量更新不同值
PHP 本身不直接“更新多条记录”，真正干活的是 SQL 的 UPDATE。最常用也最可控的方式，是在一条 UPDATE 里用 CASE WHEN 区分不同 id（或其他唯一条件）设不同字段值。
适合场景：你手头有一组 ID 和对应的新状态/价格/分类，想一次性写入，避免循环执行 N 条 UPDATE——既减少数据库往返，又保证原子性（要么全成功，要么报错回滚）。
常见错误是把多个 SET 并列写，比如 SET name='a', name='b'，这语法不合法；或者误以为 WHERE id IN (1,2,3) 就能给每行设不同值，其实它只能统一赋相同值。
- 必须用
CASE WHEN id = 1 THEN '新名A' WHEN id = 2 THEN '新名B' END给每个字段动态赋值 -
WHERE id IN (1,2,3)要和CASE中的 ID 完全覆盖，漏掉会导致该行被设为NULL（除非加ELSE） - MySQL 允许在
UPDATE中直接用子查询或 JOIN，但CASE方式兼容性最好，5.6+ 都支持
UPDATE users
SET status = CASE id
WHEN 101 THEN 'active'
WHEN 102 THEN 'pending'
WHEN 103 THEN 'blocked'
END
WHERE id IN (101, 102, 103);用 INSERT ... ON DUPLICATE KEY UPDATE 替代批量 UPDATE
当你的数据源来自数组、CSV 或 API 响应，且表有唯一键（UNIQUE 或 PRIMARY KEY），INSERT ... ON DUPLICATE KEY UPDATE 是更简洁的选择——它本质是“插入，冲突就更新”。
立即学习“PHP免费学习笔记（深入）”；
比 CASE WHEN 更少手写分支，尤其字段多、行数多时；但要求你明确知道哪个字段触发“重复”判断（比如 email 或 sku），且不能依赖自增 ID 冲突。
容易踩的坑：没建唯一索引，语句就退化成纯插入，重复数据照进不误；或者 ON DUPLICATE KEY UPDATE 后面只写部分字段，遗漏了本该更新的列。
- 必须确保冲突字段上有
UNIQUE或PRIMARY KEY索引，否则不触发更新 -
VALUES(name)引用的是本次INSERT的值，不是原记录值；如需原值 + 新值（比如计数器），得写count = count + VALUES(delta) - PHP 中拼接时注意单引号转义，建议用 PDO 的
prepare()+execute()绑定参数
INSERT INTO products (sku, price, stock)
VALUES ('P1001', 29.99, 42), ('P1002', 19.50, 18)
ON DUPLICATE KEY UPDATE
price = VALUES(price),
stock = VALUES(stock);PHP 循环执行 UPDATE 的边界情况
不是所有场景都适合单条 SQL。当每条记录的条件逻辑差异大（比如要结合 PHP 函数计算新值、调第三方 API、做权限校验），硬塞进一条 SQL 反而难维护、难调试。
这时老老实实用 PHP 循环 + 参数化 UPDATE 更稳妥。关键不是“快”，而是“可控”和“可中断”。
典型翻车点：用字符串拼接 SQL，ID 来自用户输入却没过滤，直接导致 SQL 注入；或者事务没包住整个循环，中途出错后部分更新、部分失败。
- 必须用
PDO::prepare()或mysqli_prepare()，禁止拼接$id到 SQL 字符串里 - 如果业务上要求“全部成功或全部失败”，得手动
beginTransaction()→ 循环 →commit()或rollback() - 超过 500 行建议分批（比如每次 100 条），避免超时或锁表太久
WHERE 条件太宽泛导致误更新
批量操作最危险的不是性能，是改错数据。“UPDATE orders SET status='shipped' WHERE user_id=123”看着没问题，但如果忘记加时间范围或状态过滤，可能把用户所有历史订单（包括已取消的）全标成已发货。
真实线上事故里，八成批量更新问题出在 WHERE 不够精确，而不是语法或性能。
- 执行前先用
SELECT COUNT(*)和SELECT * LIMIT 5确认影响行数和样例数据 - 涉及状态变更时，显式加上原状态条件：
WHERE status='pending' AND user_id=123 - 开发环境开
safe-updates模式（MySQL），强制UPDATE必须带KEY或LIMIT
实际写的时候，别光盯着“怎么写一条牛逼 SQL”，先问清楚：这些记录的区分依据是什么？有没有唯一约束可用？出错了能不能接受部分失败？这些问题的答案，比函数名和语法重要得多。
