mysql“行锁变表锁”本质是未走索引导致全表扫描并逐行加x锁与间隙锁，等效锁表；解决核心是确保java发出的sql真正命中索引，需通过explain验证key非null、type非all、rows合理，并规避隐式转换、字符集不匹配、like前导通配符及联合索引失效等问题。
Java 应用里 MySQL 出现“行锁变表锁”，本质不是锁升级，而是没走索引导致全表扫描，InnoDB 被迫对成百上千行逐个加行锁（含间隙锁），并发一高就卡死。解决核心只有一条：让 SQL 在 Java 中真正命中索引。
确认问题是否真由索引缺失引发
别凭感觉，从 Java 发出的 SQL 入手查执行计划：
- 把应用日志里慢的 UPDATE/DELETE/SELECT FOR UPDATE SQL 拿出来，在 MySQL 客户端跑 EXPLAIN FORMAT=JSON，重点看：
→ key 字段是否为 NULL
→ rows 是否远超实际匹配数（比如只改 1 行却显示扫描 10 万行）
→ type 是否为 ALL 或 INDEX - 开启 MySQL 慢日志并记录未用索引的查询：
SET GLOBAL slow_query_log = ON;
SET GLOBAL log_queries_not_using_indexes = ON;
配合 Java 应用压测，快速定位“藏在代码深处”的问题 SQL
Java 层确保索引被真正使用
光建索引不够，Java 代码写法常让索引失效：
-
避免隐式类型转换：比如数据库字段是 INT，但 Java 传参用了字符串
"123"→ 改成Integer.valueOf("123")或用 PreparedStatement 绑定正确类型 -
警惕字符集不匹配：MySQL 列用 utf8mb4，但 JDBC URL 或连接参数没指定
useUnicode=true&characterEncoding=utf8mb4，会导致比较时索引失效 -
LIKE 查询慎用前导通配符：
WHERE name LIKE "%admin"必然走不了索引 → 改成全文索引或业务侧改用前缀匹配（LIKE "admin%"） -
联合索引要满足最左前缀：建了
(status, create_time)，Java 里却只查WHERE create_time > ?→ 索引失效；应确保 WHERE 条件包含status = ?才能生效
优化 Java 数据访问层逻辑
很多“锁表”其实源于 Java 代码组织不当：
-
批量更新别用单条循环：避免在 for 循环里反复执行
update by id→ 改用 MyBatis 的<foreach></foreach>生成批量语句，或 JDBC BatchUpdate - 事务粒度要小：不要在 Service 方法里包裹大量无关操作（如远程调用、文件读写）再执行 DB 更新 → 把 DB 操作单独拆成短事务，减少锁持有时间
- 读写分离场景注意主库写压力：如果所有写请求都打到同一主库，即使每条 SQL 都走索引，高并发下锁竞争仍剧烈 → 可考虑分库分表，或用乐观锁 + 重试替代强一致性更新
验证与监控落地
上线后必须闭环验证效果：
- Java 应用接入 Druid 或 MyBatis-Plus 的 SQL 监控，实时看慢 SQL 和执行计划
- MySQL 侧定期查 performance_schema.data_locks：
SELECT LOCK_TYPE, LOCK_MODE, INDEX_NAME FROM performance_schema.data_locks WHERE OBJECT_NAME = 'your_table';
看到LOCK_TYPE = 'RECORD'且INDEX_NAME非 NULL，说明锁已落到索引上 - 观察 innodb_row_lock_waits 和 innodb_row_lock_time_avg 这两个状态变量，数值明显下降才算真正解决
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
