InnoDB 的行锁机制在高并发下为什么有时会退化成表锁
InnoDB 默认用行锁，但锁的粒度实际取决于是否命中索引。如果
WHERE条件没走索引（比如对非索引字段查询、隐式类型转换、函数包裹列），MySQL 会扫描全表，每行加锁 → 实际效果等同于表级锁定，阻塞严重。
常见诱因包括：
SELECT * FROM user WHERE JSON_EXTRACT(profile, '$.age') = 25：JSON 字段上无虚拟列索引，无法走索引
SELECT * FROM order WHERE order_no = 12345，但
order_no是
VARCHAR类型，传入的是整数
12345→ 触发隐式转换，索引失效 事务中执行
UPDATE前先做了
SELECT ... FOR UPDATE但没加索引条件，导致锁住所有聚簇索引记录
验证方式：执行
SHOW ENGINE INNODB STATUS\G，关注
TRANSACTIONS部分的
lock_mode X locks rec but not gap行数，若远超预期更新行数，大概率是锁范围过大。
如何让大事务不拖垮整个 MySQL 实例
长事务不仅占用锁资源，还会阻碍 purge 线程清理 undo log，导致
ibdata1持续膨胀、历史版本链过长，最终使
SELECT也变慢（需遍历更长的版本链）。
关键控制点：
禁止在应用层开启事务后「先查再等用户输入再更新」——这类交互式事务必须拆成短事务 批量更新改用INSERT ... ON DUPLICATE KEY UPDATE或分页
LIMIT+ 循环，单次事务控制在 500 行以内 监控
information_schema.INNODB_TRX表，设置告警阈值：事务运行时间 > 60 秒 或
TRX_ROWS_LOCKED> 10000 避免在事务中调用外部 HTTP 接口或写文件，这些 I/O 不可控且极易超时
示例：错误写法
BEGIN; SELECT balance FROM account WHERE id = 1001; sleep(5); UPDATE account SET balance = balance - 100 WHERE id = 1001; COMMIT;—— 这 5 秒内余额行一直被锁，高并发下直接卡死。
buffer pool 大小设多大才不浪费又不抖动
innodb_buffer_pool_size不是越大越好。设太高会导致系统内存不足，触发 Linux OOM Killer 杀 MySQL；设太低则频繁磁盘读，
Innodb_buffer_pool_wait_free计数器飙升，QPS 断崖下跌。
实操建议：
专用数据库服务器：设为物理内存的 70%～80%，但必须预留至少 2GB 给 OS 和其他进程（如备份工具、监控 agent） 与 Redis/Nginx 共存：压到 50%～60%，并观察free -h中
available是否稳定 > 1GB 关键指标看
Innodb_buffer_pool_read_requests / Innodb_buffer_pool_reads，比值 5000 说明 buffer pool 利用率高，但不意味着还能继续加 启用
innodb_buffer_pool_instances = 8（当 pool > 1GB 时），减少内部 mutex 争用
只读从库延迟突增时，SQL 线程瓶颈到底在哪
从库延迟不是主库慢，而是从库 SQL 线程（apply relay log）跟不上。常见根因不是 CPU 或磁盘，而是单线程回放瓶颈或锁等待。
排查路径：
执行SHOW SLAVE STATUS\G，重点看
Seconds_Behind_Master和
Slave_SQL_Running_State—— 若长期卡在
Waiting for dependent transaction to commit，说明启用了
slave_parallel_type = LOGICAL_CLOCK但事务依赖太强 检查
performance_schema.events_statements_history_long，过滤
THREAD_ID对应 SQL 线程，找执行时间最长的语句（常是大
UPDATE或
ALTER TABLE） 确认是否开了
innodb_flush_log_at_trx_commit = 1+
sync_binlog = 1：这种强一致性配置会让从库每次事务都刷盘，在机械盘上极易成为瓶颈 临时缓解：把大 DML 拆成带
WHERE id BETWEEN ? AND ?的小批次，避免单事务锁表太久
真正治本的方式不是调参，而是从业务侧避免「一个事务改几万行」，这类操作在主从架构下天然就是扩展瓶颈。
