大批量更新卡死服务的核心是锁范围过大和锁持有时间过长；需确保where条件走有效索引，避免隐式转换、函数包裹等导致索引失效，否则innodb会全表扫描并加记录锁与间隙锁。
大批量更新卡死服务，核心不是数据量大，而是锁住太多行太久。关键要控制单次事务的锁范围和持续时间，而不是单纯“分页”或“加索引”。
确保WHERE条件走有效索引
没索引或索引失效，InnoDB会全表扫描并逐行加记录锁+间隙锁，等效锁表。常见失效场景包括：
- 字段类型不匹配：比如
status是VARCHAR，却传入数字WHERE status = 1，触发隐式转换 - 函数包裹条件：如
WHERE DATE(create_time) = '2026-07-28'，应改写为create_time >= '2026-07-28' AND create_time - 前缀索引未覆盖查询长度：比如索引是
INDEX(name(10))，但查询用WHERE name = 'verylongusername'（超10字符）
执行前务必用EXPLAIN验证type不是ALL、rows远小于总行数。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
按主键范围分批更新，别用OFFSET分页
靠LIMIT 500 OFFSET 1000更新，MySQL仍可能重复扫描前面的行，锁范围不可控。正确做法是用主键做游标：
- 先查一批ID：
SELECT id FROM t WHERE ... ORDER BY id LIMIT 500 - 再更新：
UPDATE t SET x = y WHERE id IN (1,2,3,...)，确保IN列表顺序与查询一致 - 更稳妥方式：
WHERE id > ? AND id ，下一批起始值取上一批<code>MAX(id) - 单批控制在100–500行；若涉及多表JOIN或大字段，建议≤100
- 每批后显式
COMMIT，并加微小延迟（如SLEEP(0.01)）缓解锁队列堆积
统一多表操作顺序，杜绝交叉加锁
两个事务分别以不同顺序更新order和user表，必然形成死锁环路。这不是概率问题，是确定性风险：
- 所有业务代码必须约定唯一顺序：按表名字母序（
order_item → order → user），或按业务流向（order → order_item → payment） - 禁止根据业务类型动态拼接SQL顺序，例如不能因
type == 'refund'就先更新user再更新order - 每张表的更新都必须基于主键或唯一索引，避免
SELECT FOR UPDATE升级为宽范围间隙锁
控制事务生命周期，避免隐式状态残留
很多问题源于连接状态失控，而非SQL本身：
- 确认连接
autocommit状态：SELECT @@autocommit，必要时显式设为0：SET autocommit = 0 - 每批更新必须用
BEGIN和COMMIT显式包裹，不能依赖ORM自动提交 - 避免在事务中混用
SELECT FOR UPDATE或LOCK IN SHARE MODE，它们会延长锁持有时间 - 使用连接池时，每次分批前执行
RESET CONNECTION或重新获取连接，防止复用未清理的事务上下文
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
