数据库监控体系日趋完善，CPU升高、I/O波动、会话堆积、慢SQL等异常已能被快速发现。但真正的挑战在于异常出现后的根因定位——一次性能问题可能同时涉及服务器资源、SQL执行、锁等待、长事务、索引等多个因素，DBA需在不同页面间反复切换、凭经验拼接线索。

为此，KEMCC构建了覆盖性能、锁、根因、SQL、存储、索引及SQL统计的完整诊断框架，核心是将分散的诊断信息关联成一条可连续下钻的分析链路，让排障从**“看到异常”**走向“找到原因”。

1 从一个异常时间点开始，把线索串起来

当数据库响应变慢，常规做法是先看CPU、IO、TPS、QPS、会话数等指标。但单条性能曲线无法回答“因何而起”。

KEMCC性能分析将服务器资源与数据库核心指标置于统一时间轴，当某时段出现慢SQL或长事务，可直接关联对应语句。排障不再停留于“指标波动”，而是追问：“异常时数据库在执行什么？”

性能分析页面：服务器+数据库指标+异常SQL联动

2 SQL为什么慢？继续看“谁在等谁”

锁等待是并发场景下影响响应时间的重要因素。一条SQL自身可能不慢，但若前序事务长期持锁，后续会话仍会持续等待。仅看SQL耗时易被表象误导。

KEMCC锁分析集中展示锁等待、死锁、长事务，并呈现等锁SQL、加锁SQL及等待时长。

• 锁次数柱状图+等锁列表
  

• 等锁流程图：谁持锁、谁等锁、等待多长时间

等锁流程图直观还原会话间的持锁与等待关系，帮助DBA快速判断SQL慢是**“自身效率低”还是“被其他事务阻塞”**。

3 从现象继续追到根因

实际生产中的性能问题常是多因素叠加：长事务、低效SQL、索引缺失、资源波动共同作用。单独看每项都是局部异常，唯有判断因果关系才能锁定根因。

KEMCC根因分析汇总问题SQL，结合影响时长、锁详情、执行计划进行关联分析，辅助判断问题来源。

例如，一条业务SQL持续变慢且伴随锁等待，继续追溯可能发现后台长事务持锁，而SQL自身执行效率低，导致持锁时间延长，其他会话等待累积，最终业务响应变慢——慢SQL、长事务、锁等待不再孤立，而是形成完整问题链。

根因分析：左侧根因SQL+右侧分析结果+修复建议

若问题指向索引，可进一步通过索引分析检查缺失、无效或低效索引；通过SQL统计分析查看调用次数、总耗时、平均耗时及历史执行计划。

完整排查路径清晰连贯：发现异常→锁定问题SQL→分析等待关系→判断问题来源→辅助优化

SQL分析：高危/可疑/慢/关注四态列表+趋势图

4 少一些反复排查，多一些有依据的判断

KEMCC的故障诊断框架并非简单叠加功能，而是让七类分析协同工作：

1. 性能分析：定位异常时空
2. SQL分析：锁定关注语句
3. 锁分析：还原等待关系
4. 根因分析：关联线索并判断来源
5. 索引、SQL统计：提供优化依据

过去需要人工在不同页面间寻找联系，现在KEMCC将信息纳入统一诊断链路，减少页面切换，使排障更连续。

核心目标不仅是**“看得见”异常，更是“找得到”**根因，从而缩短排查路径，提供清晰线索和可靠判断。