单条UPDATE语句本身无法保证多线程并发下的数据安全，必须配合事务、锁机制或乐观控制手段；MySQL默认autocommit=1，每条UPDATE自成事务、锁瞬时释放，易导致覆盖写、ABA问题等。
直接说结论：靠单条 UPDATE 语句本身无法保证多线程并发下的数据安全，必须配合事务、锁机制或乐观控制手段，否则大概率出现覆盖写、ABA问题、死锁或不可重复读。
UPDATE WHERE 不加事务等于裸奔
很多人以为写了 WHERE id = ? 就万事大吉，其实不是。MySQL 默认自动提交（autocommit=1），每条 UPDATE 自成一个事务，锁只在语句执行期间持有——刚改完就释放，中间完全暴露给其他并发请求。
- 后果：两个事务同时读到同一行旧值（比如库存=10），各自减1后都写回9，实际应剩8
- 必须显式用
BEGIN/START TRANSACTION包裹操作，让锁持续到COMMIT或ROLLBACK - 检查当前会话是否在事务中：查
SELECT @@in_transaction，返回 1 才算真正进事务
SELECT FOR UPDATE 在什么情况下失效
SELECT ... FOR UPDATE 是常用悲观锁手段，但它有严格前提，不满足就形同虚设。
- 只在事务内生效：不在
BEGIN后执行，它退化为普通SELECT - 依赖隔离级别：在
READ COMMITTED下，锁只保到语句结束；必须设为REPEATABLE READ或更高，锁才持续到事务结束 - WHERE 条件必须走索引：如果
SELECT FOR UPDATE WHERE status = 'pending'，而status没索引，InnoDB 可能升级为表锁，或根本锁不住目标行 - 后续
UPDATE的条件必须和SELECT完全一致：不能SELECT id加锁，然后UPDATE ... WHERE status = ? AND id = ?，否则锁可能不复用
乐观锁怎么避免“看似成功实则错乱”
用 version 字段做乐观锁比纯 WHERE status = 'old' 更可靠，但仍有关键细节容易漏。
- 必须检查影响行数：
ROW_COUNT()返回 0 说明条件不匹配（比如 version 已被别人更新），此时不能静默忽略，得重试或报错 - version 更新要原子：
UPDATE t SET balance = balance - 100, version = version + 1 WHERE id = 123 AND version = 5，不能拆成两条语句 - 避免前端传 version：version 应由数据库生成并返回，防止客户端篡改或缓存旧值
- 时间戳不如 version 稳定：
updated_at = NOW()在高并发下可能重复，且时钟不同步时更危险
WHERE 条件没走索引，锁就失控了
这是最隐蔽的性能与安全双杀点。即使你写了 WHERE，只要没命中索引，InnoDB 就没法精准加行锁。
- 执行
EXPLAIN看type字段：要是ALL（全表扫描），那UPDATE或SELECT FOR UPDATE实际锁的是整张表 - 复合索引要注意最左前缀：
INDEX(a,b)支持WHERE a = ?，但不支持WHERE b = ? - 隐式类型转换会让索引失效：
WHERE user_id = '123'（字符串） vsuser_id是INT，会导致全表扫描 - 线上紧急补救：先用
SHOW ENGINE INNODB STATUS\G查当前锁等待，再针对性加索引
真正难的不是知道要用事务或加锁，而是每个环节都得对齐：事务开启时机、隔离级别设置、索引覆盖范围、WHERE 条件一致性、影响行数校验——漏掉任何一环，高并发下数据就可能无声无息地错掉。
