本层负责什么
数据与缓存层的故障往往表现为应用整体变慢，但真正原因可能是锁等待、执行计划变化、连接耗尽、容量边界或缓存策略。诊断应从受影响请求追到具体会话和命令，先确认一致性与阻塞关系，再评估索引、事务或容量调整，避免把所有慢请求归因于“数据库性能”。
常见症状
这些现象用于判断排查入口，不代表已经确定根因。先记录原始错误和时间，再执行首轮检查。
- 查询延迟突然升高、执行计划变化或扫描行数异常
- 事务等待、死锁、连接池耗尽或活跃会话大量堆积
- Redis 达到 maxmemory、写入被拒绝或淘汰率异常
- 缓存命中率骤降、热点键放大后端压力或数据不一致
首轮检查清单
按顺序执行并保存输出。每一步只改变一个变量，避免让恢复动作覆盖真正的失败证据。
- 定位具体操作记录请求时间、数据库实例、库表、语句摘要和调用方，避免只看全局平均值。
- 检查会话与阻塞确认谁在等待、谁持有锁、事务已持续多久，并保存处理前的证据。
- 核对计划与容量查看执行计划、索引命中、内存策略、连接数和磁盘空间，区分结构问题与资源边界。
- 设计可回滚验证在代表性数据和相同查询参数下比较改动前后结果，同时验证返回数据一致。
操作边界
读取会话、计划和统计信息通常风险较低，但 EXPLAIN ANALYZE、全表扫描和大范围 key 查询可能产生真实负载。终止事务、添加索引、扩容或调整淘汰策略前必须确认业务影响和回滚方案。
何时升级或切换层级
当证据指向其他系统边界，立即带着时间、环境和原始输出交接，避免在当前层重复执行无关操作。
- 需要终止生产事务或修改表结构：由数据库负责人评估并审批。
- 上游请求模式突变或出现重试风暴：把证据交给应用与网关负责人协同处理。
- 磁盘、文件系统或主机内存成为共同瓶颈：转入系统与安全层。