不能直接全表UPDATE时间戳，因会引发锁等待堆积、undo日志暴涨、主从延迟飙升三重风险；必须分批+索引驱动更新，如用主键BETWEEN分段或临时表JOIN精准定位目标行。
UPDATE 百万级数据的时间戳字段，**不能直接写 UPDATE table SET updated_at = NOW()**——这会锁表、压爆 undo 日志、拖垮主从延迟，甚至触发 OOM。真正可行的方案是分批 + 索引驱动 + 避免全表扫描。
为什么不能直接全表 UPDATE 时间戳？
MySQL 的 UPDATE 在 InnoDB 中默认走行锁，但百万级无 WHERE 条件或 WHERE 无索引时，会退化为“逐行加锁 + 全表扫描”，带来三重风险：
– 锁等待堆积，阻塞所有读写请求
– undo 日志暴涨（每行旧值都要存），可能填满 ibdata1 或独立 undo 表空间
– 主库 binlog 写入巨大，从库重放慢，延迟飙升到小时级
– SHOW PROCESSLIST 里长期卡在 Updating 状态，且 Rows_examined 持续增长
必须用主键分段 + LIMIT 分批更新
核心思路：用自增主键（或有索引的递增字段）切片，每次只更新几千行，控制事务体积和锁持有时间。
示例语句（假设表 orders 主键为 id）：
UPDATE orders SET updated_at = NOW() WHERE id BETWEEN 100000 AND 104999;
关键操作建议：
– 先查出最小和最大
id：SELECT MIN(id), MAX(id) FROM orders– 批次大小设为 5000～10000，太大易超时，太小网络开销高
– 每批执行后加
SLEEP(0.05)（如用存储过程），避免 CPU 和 IOPS 扛不住– 务必在
WHERE 中使用已建索引的字段，禁止 WHERE DATE(created_at) = '2025-01-01' 这类无索引表达式– 检查执行计划：
EXPLAIN UPDATE ... 必须显示 type: range 且 key 列非 NULL
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
用临时表 JOIN 更新（适合条件复杂或非主键驱动场景）
当你要更新的记录不连续、或判断逻辑依赖其他表/函数（比如只更新“最后更新距今超 7 天”的记录），直接分批难定位，这时用临时表更可控：
CREATE TEMPORARY TABLE tmp_ids AS SELECT id FROM orders WHERE updated_at < DATE_SUB(NOW(), INTERVAL 7 DAY) LIMIT 10000;<br>UPDATE orders o JOIN tmp_ids t ON o.id = t.id SET o.updated_at = NOW();
注意点：
–
CREATE TEMPORARY TABLE 只对当前会话可见，安全– 第一步
SELECT 必须带 LIMIT，防止临时表本身撑爆内存–
JOIN 更新比子查询快，且能利用 tmp_ids.id 的隐式索引– 执行完删掉临时表不是必须的，会话断开自动清理
别忽略时区和字段类型陷阱
时间戳字段类型选错或时区配置不一致，会导致 NOW() 值不符合预期：
– 如果字段是 TIMESTAMP，它会自动转成系统时区存储；DATETIME 则原样存，不转换
– 查看当前时区：SELECT @@time_zone, @@system_time_zone
– 若应用层用 UTC，但 MySQL 服务端设的是 Asia/Shanghai，NOW() 就会多 8 小时
– 更稳妥的做法是显式用：CONVERT_TZ(NOW(), '+00:00', '+08:00') 或直接存 UTC：UTC_TIMESTAMP()
– ON UPDATE CURRENT_TIMESTAMP 对 DATETIME 字段无效（仅 TIMESTAMP 支持），别指望它自动生效
CURRENT_TIMESTAMP 的隐形影响——这些细节不手动验证一遍，很容易在凌晨两点收到告警。 
