update没走索引会全表扫描并逐行加记录锁与间隙锁，等效锁表；需用explain确认索引使用、避免隐式转换和函数操作、分批基于主键范围更新、控制事务时长并统一多表操作顺序。
UPDATE没走索引直接锁全表
这是最常见也最危险的情况：WHERE条件字段没索引，或索引因隐式转换、函数包裹而失效，InnoDB被迫全表扫描——每扫一行就加一个记录锁，间隙锁也会自动激活，效果等同于锁整张表。
典型现象是：SHOW PROCESSLIST里大量连接卡在Locked或Waiting for table metadata lock；EXPLAIN显示type: ALL且rows接近表总行数。
- 先用
SHOW INDEX FROM table_name确认目标字段是否有可用索引（注意前缀索引是否覆盖查询长度） - 检查WHERE条件是否触发隐式转换，比如
mark_id是VARCHAR却传入数字123 - 避免
WHERE DATE(created_at) = '2026-06-01'这类写法，改用created_at >= '2026-06-01' AND created_at - 紧急时可用
FORCE INDEX强制走索引，但只是临时手段，长期要修复执行计划
批量UPDATE按主键范围分批才真正可控
即使WHERE条件走了索引，一次性UPDATE几千上万行仍会持续持有大量X锁，极易引发锁等待甚至死锁。关键不是“有没有索引”，而是“单次事务锁住多少行+多久”。
按OFFSET分页（如LIMIT 500 OFFSET 1000）不行——MySQL仍可能重复扫描前面的行，锁范围不可控。必须用主键范围切分。
- 先
SELECT id FROM t WHERE ... ORDER BY id LIMIT 500拿到一批ID，再构造WHERE id IN (1,2,3,...) - 更稳妥的是
WHERE id BETWEEN ? AND ?，起始值取上一批的MAX(id)，避免漏或重 - 单批控制在100–500行之间，但别硬套——若更新涉及多表JOIN或大字段，建议缩到100以内
- 每批后显式
COMMIT，并加SLEEP(0.01)缓解CPU和锁争抢
多表UPDATE顺序不一致必然引发死锁
两个事务分别以不同顺序更新order和user表，InnoDB加锁就会形成环路。这不是概率问题，是确定性死锁源，占比超四成。
死锁日志里常看到TRANSACTION 123456789 locks record but not gap和另一事务waiting for this lock to be granted交替出现。
- 所有多表操作必须约定唯一顺序：按表名字母序（
order_item → order → user）或业务主次（订单流必须order → order_item → payment） - 禁止在代码里用if/else动态拼接UPDATE顺序，例如不能根据
type == 'refund'决定先更新user还是order - 每个表的访问都必须走主键或唯一索引，否则
SELECT FOR UPDATE可能升级为间隙锁，扩大冲突面 - 事务内只保留查→算→写三步，HTTP调用、Redis读写、日志落盘全部移出事务块
事务太长才是锁问题的放大器
UPDATE本身可能只要几毫秒，但事务里混了第三方API调用、循环处理、日志写入，导致锁持有时间从毫秒级拉长到秒级——这期间所有相关行都被锁死，其他请求只能排队等。
INFORMATION_SCHEMA.INNODB_TRX里能看到trx_started早于trx_query执行时间，trx_state = RUNNING但长时间没提交。
- 用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'RUNNING' AND TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 2快速揪出长事务 - ORM框架（如Spring
@Transactional）要严格审查事务边界，避免把非DB操作包进去 - 连接池复用场景下，务必确保每个请求结束时显式
COMMIT或ROLLBACK，不能依赖连接关闭自动清理 - 生产环境慎调
innodb_lock_wait_timeout，设小了只是让报错更快，锁本身还在；设大了掩盖热点行问题
真正容易被忽略的是：锁问题从来不是孤立SQL的问题，而是事务设计、索引策略、应用逻辑三者耦合的结果。一个WHERE id IN (...)看似安全，但如果IN列表来自未排序的子查询，或事务外缓存了过期ID，照样会漏数据或重复更新。
