默认情况下，mysql多线程同时update同一行时后到请求被阻塞等待而非报错，由innodb行级锁与next-key lock机制保证顺序执行；where条件未走索引会导致全表扫描并逐行加锁，引发严重性能下降。
MySQL 更新同一行时会卡住还是报错？
默认情况下，多线程同时执行 UPDATE 同一行，后到的请求不会报错，而是被阻塞等待——直到前一个事务提交或回滚释放锁。这是 InnoDB 的行级锁 + next-key lock 在起作用，不是“谁快谁赢”，而是“谁先拿到锁谁先执行”。
常见错误现象：
– 应用日志里突然出现大量 Lock wait timeout exceeded
– 某条 UPDATE 执行时间从几毫秒飙到 50 秒以上
– SHOW PROCESSLIST 里看到状态长期卡在 Updating 或 Waiting for table metadata lock（注意：后者通常是 DDL 导致，不是行锁）
实操建议：
– 用 SELECT ... FOR UPDATE 显式加锁前，确认业务是否真需要强一致性；多数场景用 UPDATE ... WHERE 带条件+唯一索引就能安全并发
– 检查是否无意中触发了间隙锁（比如 WHERE id > 100 但没走索引），导致锁住一片范围
– 避免在事务里混用 SELECT 和 UPDATE，尤其跨表时容易扩大锁范围
UPDATE 语句没走索引会导致全表锁吗？
不会全表锁，但可能锁住远超预期的行数。InnoDB 只能对索引记录加行锁，如果 UPDATE 的 WHERE 条件没命中索引，它会扫描全表（或全索引），对**每一条扫描到的记录都尝试加锁**——实际效果接近“伪全表锁”，并发性能断崖下跌。
使用场景：
– 日常运营后台批量修正数据，WHERE status = 'pending' 却没给 status 加索引
– 临时脚本直接 UPDATE users SET name = ? WHERE created_at ，而 <code>created_at 无索引
实操建议：
– 执行前一定看 EXPLAIN UPDATE ...（MySQL 8.0.19+ 支持，低版本可用 EXPLAIN SELECT 模拟）
– 如果必须扫全表，考虑分批更新：UPDATE ... WHERE id BETWEEN ? AND ?，配合主键切片
– 别依赖 FORCE INDEX 强行走索引——如果索引区分度极低（比如性别字段），优化器不选它反而是对的
REPEATABLE READ 隔离级别下更新会幻读吗？
不会产生幻读更新，但可能因 gap lock 导致“看似幻读”的阻塞。比如事务 A 执行 UPDATE orders SET status = 'shipped' WHERE user_id = 123 AND status = 'paid'，此时事务 B 插入一条 user_id = 123, status = 'paid' 的新订单——B 会被阻塞，直到 A 提交。这不是幻读（幻读指 SELECT 多出记录），而是 gap lock 主动拦住了插入。
参数差异：
– innodb_locks_unsafe_for_binlog = ON（已废弃）或 READ COMMITTED 隔离级别下，gap lock 被禁用，B 不会阻塞，但 A 的两次 SELECT ... FOR UPDATE 可能读到不同结果
– MySQL 8.0 默认 READ COMMITTED 对普通 UPDATE 也只加 record lock，不加 gap lock
实操建议：
– 不要为了“避免幻读”盲目降级隔离级别，先确认业务是否真容忍更新丢失或中间态不一致
– 如果确定不需要 gap lock（如纯追加日志表），可设会话级 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
– INSERT ... ON DUPLICATE KEY UPDATE 是更轻量的并发更新方案，冲突时直接改，不触发 gap lock
用 SELECT FOR UPDATE + UPDATE 两步走安全吗？
不安全，反而更容易死锁且性能更差。两步操作把原本一次完成的锁获取和数据修改拆开，中间窗口期可能被其他事务插入/修改，还额外增加一次网络往返和锁持有时间。
常见错误现象：
– 同一事务里先 SELECT id FROM t WHERE ... FOR UPDATE，再根据结果拼 UPDATE t SET ... WHERE id = ?，结果 id 对应的行已被删或改
– 多个服务同时查同一批 ID，各自按不同顺序加锁，触发死锁（Deadlock found when trying to get lock）
实操建议：
– 优先用单条 UPDATE ... WHERE 原子更新，条件尽量覆盖业务唯一性约束（如 WHERE order_no = ? AND status = 'unpaid'）
– 必须两步时，确保 SELECT FOR UPDATE 的 WHERE 条件和后续 UPDATE 的 WHERE 完全一致，且走相同索引
– 死锁无法完全避免，应用层要捕获 Deadlock found when trying to get lock 并重试，但重试次数别超过 3 次
真正难处理的从来不是“会不会锁”，而是锁的粒度、范围和持续时间藏在 SQL 写法、索引设计、事务边界这些地方——一不留神，一个 WHERE 少加索引，就让十倍并发量直接归零。
