SQL执行统计与性能画像的核心是将执行日志转化为可定位、可对比、可归因的结构化视图，关键在于精准选字段、合理聚合维度、快速识别异常；必存5类基础字段（SQL指纹、耗时、扫描行数、返回行数、执行次数），需统一指纹生成规则；须按business_tag+SQL指纹双层聚合，并建立动态基线与执行计划快照机制。
SQL执行统计与性能画像的核心，是把零散的执行日志转化为可定位、可对比、可归因的结构化视图。关键不在于采集多全，而在于字段选得准、聚合维度对、异常识别快。
抓关键指标：不是所有字段都值得存
高频慢SQL诊断最依赖5类基础字段：SQL指纹（去参数化后的标准化文本）、执行耗时（duration_ms）、扫描行数（rows_examined）、返回行数（rows_sent）、执行次数（count）。其中SQL指纹必须统一生成规则（如用正则替换字面量为?，忽略空格和换行），否则相同逻辑的SQL会被拆成多个“假热点”。错误示例：直接记录原始SQL，导致SELECT * FROM user WHERE id=1001和SELECT * FROM user WHERE id=1002被当作两条独立语句。
- 必存字段：指纹、平均/最大耗时、P95耗时、总执行次数、总扫描行数、错误码频次
- 建议存字段：执行计划哈希（用于识别执行计划突变）、数据库名、用户账号、客户端IP（用于归属分析）
- 可丢弃字段：完整SQL原文（除非需审计）、线程ID、时间戳精确到毫秒（聚合后只需分钟级粒度）
按业务维度聚合：让数据能对得上人
单纯按SQL指纹聚合只能看到“哪条SQL慢”，但无法回答“哪个服务/哪个功能在拖慢系统”。需要在采集端或预处理阶段注入业务标签：
- 在应用层打标：MyBatis拦截器或Spring AOP中提取Mapper接口名+方法名，作为
business_tag - 在代理层打标：ShardingSphere或ProxySQL配置SQL注释解析规则，识别
/* service=order, method=create */这类标记 - 聚合时保留至少两层：先按
business_tag + SQL指纹分组，再向上卷到business_tag汇总，便于快速下钻
动态基线识别：避免用固定阈值误杀
把“耗时>1s”设为慢SQL阈值会漏掉高频轻量查询的累积影响，也会误报低峰期的合理波动。应基于历史行为自动计算动态基线：
- 对每个SQL指纹，每小时计算其过去7天同期的P90耗时，作为当前小时基线
- 当实时P95耗时 > 基线 × 2 且持续3个采样周期，触发“性能劣化”标记
- 对扫描行数突增（如比基线上升5倍），单独告警——这往往意味着索引失效或条件未走索引
执行计划快照留存：查问题时少一次复现
很多性能问题只在特定数据分布或并发下出现，等收到告警再去explain，现场已不可复现。应在检测到异常SQL时自动捕获执行计划：
- 配置策略：对P95耗时Top 10% 或 扫描行数Top 5% 的SQL，自动执行
EXPLAIN FORMAT=JSON并存入plan表 - plan表字段至少包含：SQL指纹、采集时间、query_plan_json、used_index、key_len、rows_estimated
-
前端展示时，将当前计划与最近一次正常计划做diff（比如
type从ref变成ALL，或key从idx_user_id变成NULL）
不复杂但容易忽略。重点是让每条统计记录背后都能快速连到业务动作、执行逻辑和数据特征。
