TiKV 的悲观锁默认使用内存路径以减少加锁延迟，但在非计划的 Leader 切换时可能会丢失锁。锁的 TTL 动态调整，长事务依赖心跳续期。死锁检测采用集中式方案，Leader 切换时清空历史依赖，存在漏检风险。TiKV 的锁机制与传统数据库相似，需纠正对其“无锁”的误解。

本文探讨MySQL InnoDB配置中的常见陷阱，强调buffer pool大小需预留余量以防OOM，持久性参数需成对理解，锁等待超时与死锁检测相互独立，连接数乘以缓冲区可能超出内存。提供症状、查验方法及边界清单，并与PostgreSQL配置对比，提醒配置变更需可回滚并监控验证。