mysql 5.7中索引失效导致全表扫描和锁膨胀，需通过explain确认type=all、key=null、rows≈总行数；修复须避免函数、隐式转换、最左前缀断裂，并改用范围查询或统一参数类型。
MySQL 5.7 中因索引失效引发整表扫描，进而导致 UPDATE/DELETE 持有大量行锁甚至退化为表级锁定——这不是“锁太狠”，而是优化器根本没走索引，被迫逐行加锁。修复核心不在调参，而在让索引真正被用上。
查执行计划确认是否真没走索引
别猜，直接看 EXPLAIN 输出。重点盯三个字段：
-
type是ALL（全表扫描）而不是range、ref或eq_ref -
key是NULL，说明没选任何索引 -
rows接近表总行数（比如表有 10 万行，rows=98234）
只要这三项同时出现，基本可断定是索引失效触发了锁膨胀。注意：即使 WHERE 条件看起来“很合理”，也要实测——比如 WHERE DATE(create_time) = '2024-01-01' 就必然让 create_time 索引失效。
常见失效场景及对应修复动作
5.7 不支持函数索引，所以必须绕开函数、类型转换、最左前缀断裂这些硬伤：
- 对时间列用
DATE()、YEAR()等函数 → 改成范围查询：WHERE create_time >= '2024-01-01' AND create_time - 字符串字段传数字（如
WHERE phone = 13800138000）→ 显式加引号：WHERE phone = '13800138000' - 联合索引
(a, b, c)，但只查WHERE b = 1 AND c = 2→ 补最左列条件，或重建索引为(b, c)（如果业务高频） -
WHERE name LIKE '%abc'→ 无法用索引，5.7 又不支持全文索引加速，只能改业务逻辑或加冗余字段（如倒序存储rev_name+LIKE 'cba%'）
验证索引是否真生效
建完索引别急着上线，先用 EXPLAIN FORMAT=JSON 看优化器决策细节：
- 检查
used_key_parts是否包含你期望的列 - 看
key_length是否符合预期（比如VARCHAR(50)字段实际只用了前 20 字节，key_length就不会到最大值） - 执行
ANALYZE TABLE table_name强制更新统计信息，避免优化器因旧统计误判
特别注意：已有 (a, b) 索引时，再单独建 (a) 是冗余的，5.7 不会自动合并，反而增加写开销。
锁退化后如何快速止损
若已发生阻塞，别等事务超时，立刻干预：
- 查长时间运行事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - TRX_STARTED) > 60 - 看锁住多少行：
TRX_ROWS_LOCKED远大于TRX_ROWS_MODIFIED（比如锁 50 万行只改 1 行）→ 基本就是扫描失控 - 杀掉问题事务：
KILL <code>TRX_MYSQL_THREAD_ID（注意不是TRX_ID） - 临时禁用慢查询日志中“未用索引”的记录（
log_queries_not_using_indexes = OFF），避免日志刷爆磁盘
最易被忽略的一点：索引建对了，但应用层传参类型不一致（比如 Java 用 Long 传给 VARCHAR 字段），这种隐式转换在 5.7 下完全静默失效，必须从 ORM 日志或 MySQL general_log 里抓原始 SQL 才能发现。
