不可行。Hyperf 的 update() 方法仅支持单条件批量设值，无法实现“按不同主键更新不同字段值”；正确方式是用 INSERT ... ON DUPLICATE KEY UPDATE 一条 SQL 原子完成，需确保表有主键或唯一索引，并显式指定更新字段（如 updated_at=VALUES(updated_at)）。
Hyperf 中用 update 方法批量更新单表多行是否可行？
不可行。update 方法（如 $query->update(...)）在 Hyperf 的 Db 组件中只支持单条记录的 WHERE 条件 + SET 值，底层调用的是 PDO 的 prepare/execute，无法原生表达「按不同主键更新不同字段值」的语义。
常见错误现象是：写了个循环反复调用 update，看似能跑通，但每条都是独立 SQL，N 条更新触发 N 次网络往返和事务开销，QPS 直接腰斩；若没手动包事务，还可能部分成功部分失败。
真正可落地的批量更新，必须靠一条 SQL 实现 —— 即 MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE 语法，或更稳妥的 REPLACE INTO（需注意主键/唯一键冲突逻辑）。
用 INSERT ... ON DUPLICATE KEY UPDATE 实现安全批量更新
这是 Hyperf 场景下最简、最可控的方式。前提是目标表有主键或唯一索引（否则无法触发「duplicate」分支），且你允许用「先插入再覆盖」的语义。
实操建议：
- 构造一个二维数组，每个子数组对应一行待更新数据，字段名必须与数据库列名严格一致（包括大小写）
- 用
Db::insert()批量插入，但传入第 3 个参数为['on duplicate key update' => 'col1=VALUES(col1), col2=VALUES(col2)'] - 注意：MySQL 的
VALUES(col)是特殊函数，表示「本次 INSERT 尝试插入的该列值」，不是 PHP 变量 - 如果字段含 NULL 或空字符串，要确保数据库列允许 NULL，否则
ON DUPLICATE分支会报错
示例：
$data = [
['id' => 1, 'status' => 'done', 'updated_at' => date('Y-m-d H:i:s')],
['id' => 2, 'status' => 'pending', 'updated_at' => date('Y-m-d H:i:s')],
];
Db::table('task')->insert($data, [], [
'on duplicate key update' => 'status=VALUES(status), updated_at=VALUES(updated_at)'
]);
为什么不用 Db::transaction 包循环 update？
性能差是其次，关键在于并发风险：即使加了事务，循环里每次 update 都是独立 SELECT + UPDATE（InnoDB 的当前读），若中间有其他进程修改了某条记录，第二次 update 可能覆盖掉别人刚写的值，形成「丢失更新」。
而 INSERT ... ON DUPLICATE KEY UPDATE 是原子操作，MySQL 内部用意向锁+行锁保证整条语句的隔离性，天然规避该问题。
另外注意兼容性：ON DUPLICATE KEY UPDATE 是 MySQL 特有语法，不能跨数据库移植；如果你项目未来要切到 PostgreSQL，得改用 INSERT ... ON CONFLICT DO UPDATE，Hyperf 的 Db 组件目前不自动适配这种差异，需手动判断方言。
批量更新时 updated_at 字段怎么自动刷新？
MySQL 的 ON DUPLICATE KEY UPDATE 不触发 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 的自动行为，必须显式写进更新列表里。
常见踩坑点：
- 漏写
updated_at=VALUES(updated_at)，导致时间戳永远不变 - 用
updated_at=NOW()替代，会导致所有行更新时间变成同一毫秒值，失去顺序区分能力 - PHP 层生成时间字符串时没统一时区（如 DB 是 UTC，PHP 是 Asia/Shanghai），造成时间错位
推荐做法：PHP 层统一用 date('Y-m-d H:i:s') 生成，且确保 PHP 和 MySQL 时区一致（检查 php.ini 的 date.timezone 和 MySQL 的 time_zone 变量）。
真正难点不在语法，而在确认「哪些字段必须显式参与 ON DUPLICATE 更新」以及「冲突键是否覆盖业务预期」——比如用联合唯一索引做冲突条件时，稍不注意就会误更新不该动的行。
