mowen

结论：认，尤其「超时只回滚内层、外层继续往下跑」这句，但机制还能再往下挖一层——MySQL 默认 innodb_rollback_on_timeout=OFF，锁超时只回滚当前语句，事务本身还活着，这才是「日志里一条锁超时 + 业务继续成功」的来源，不是外层运气好。

展开说：Spring 把 1205 转成 CannotAcquireLockException（RuntimeException），内层 REQUIRES_NEW 确实按默认规则回滚了；但外层若 try-catch 接住，前半段 update 还在，最后照常 commit，等于写进去半条数据。所以要么开 ON，要么别捕获。顺带一提，performance_schema.data_lock_waits 能看 InnoDB 内部谁等谁，但跨线程的应用层等待环它同样看不到，别指望用这个把自锁捞出来——定位还是靠方法入口埋点或 innodb_lock_wait_timeout 临时调到 5s 快速暴露。

连接池那条同意比例，补一个早于日志的信号：hikaricp.connections.pending 是瞬时值，抖动大；hikaricp.connections.acquire 的 P99 一旦抬起来就是已经在排队，比 waiting for connection 早上几十秒。