一、统计信息为何失真以及采集频率的取舍

优化器选错计划，八成情况下是统计信息与真实数据分布对不上。默认采样比例在小表上足够，在数十亿行的大表上，一个百分之一的采样很可能完全错过倾斜值。判断方法很直接：把优化器估算的返回行数与实际执行返回的行数做比对，偏差超过一个数量级的节点就是重点怀疑对象。

采集频率的取舍要看写入模式。追加写为主的日志表，数据分布随时间迁移，按行数变化比例触发采集容易滞后，更适合按时间窗口定期采集并对最新分区单独统计。更新密集的业务表则相反，按变更行数占比触发更贴合实际，阈值可以从默认的百分之十下调到百分之五。

直方图是处理倾斜的关键工具。对存在明显热点值的列，例如状态码、租户标识，建立频率直方图后，优化器才能区分查询的是热点值还是长尾值。某订单表的状态列只有六个取值，其中一个占比超过百分之八十，建立直方图前后，同一条查询的估算行数从三十万修正为两千四百，计划也从全表检索改为索引检索，执行耗时由九点二秒降到零点一一秒。分区表的统计信息要额外留意。全局统计与分区统计各有用途，若只维护全局统计，针对单分区的查询估算会明显偏大。建议对活跃分区单独采集，历史分区在数据冻结后采集一次即可，之后不再更新，既保证准确又不浪费资源。采集任务本身也要限流，防止在业务高峰触发全表采样。

二、索引选择性评估与组合索引列序设计

索引选择性是决定索引是否值得建立的首要指标。选择性等于不同取值数量与总行数之比，越接近一越有价值。性别、是否删除这类低选择性列单独建索引几乎没有意义，但作为组合索引的后置列仍可能有用，因为它能让索引覆盖更多查询字段，规避回表操作。

组合索引的列序遵循等值在前、范围在后、排序列紧随的原则。若查询条件是租户标识等值、创建时间范围、按更新时间排序，那么租户标识放首位、创建时间其次，排序列能否放入索引则取决于是否与范围列冲突。一个常见误区是把区分度最高的列无脑放首位，忽略了实际查询是否总带该条件，结果索引根本用不上。

索引不是越多越好。每个二级索引都会带来写入放大，插入一行需要维护全部索引结构。某业务表挂了十一个索引，写入吞吐只有同规格空表的三分之一。清理时可以先采集索引使用统计，把连续三十天零命中的索引下线，再把功能重叠的索引合并。该表最终保留五个索引，写入吞吐提升一点九倍，而查询时延没有出现明显退化。覆盖索引是另一个值得利用的手段。当索引包含查询所需的全部字段时，执行引擎无需回表，随机读次数可以下降一个数量级。代价是索引变宽，占用更多缓存空间，因此只对高频查询做覆盖设计，且字段数量控制在五个以内。判断是否生效很简单，看执行计划中是否出现仅索引访问的标记即可。

三、慢查询的采集、聚类与根因归并

慢查询治理的第一步是把日志收全。阈值设得过高会漏掉大量中等耗时但调用频繁的语句，这类语句对整体资源的消耗往往超过偶发的超长查询。建议把阈值下调到二百毫秒，同时开启采样，防止日志量本身成为新的负担。

原始慢日志不能直接看，必须先做参数化聚类。把字面量替换为占位符后按模板归并，统计每个模板的调用次数、总耗时、均值耗时与扫过行数，按总耗时排序。这样得到的榜单才反映真实的资源消耗结构，通常前十个模板会占到总耗时的七成以上。

根因归并要分类处理。缺索引类的特征是扫过行数远大于返回行数；计划抖动类的特征是同一模板耗时方差极大；锁等待类的特征是执行时间长但扫过行数很少；参数不当类则表现为某几个参数取值下耗时异常。分类之后，处置手段就很明确：补索引、绑定计划、拆分事务或改写语句。把这套流程固化成周报，某系统三个月内把数据服务的整体查询耗时降低了百分之五十八，效果远好于零散优化。还要关注被慢日志遗漏的部分。有些语句单次执行很快，但在循环中被调用数千次，总耗时惊人，这类问题只能通过应用侧的调用统计发现。把数据访问层的调用次数与耗时上报到监控，与慢日志形成互补，才能看到完整的资源消耗图景。某服务据此发现一处循环内查询，改为批量获取后接口耗时下降八成。

四、治理闭环：从变更评审到效果回归

治理要形成闭环，关键是把变更纳入评审。新增索引、修改语句、调整参数都应提交变更单，附上变更前后的执行计划、预估影响的表规模与回滚方案。评审重点不是语法对错，而是这次变更会不会让写入路径变慢、会不会与既有索引重叠造成浪费。

效果回归需要基线数据。变更前先记录目标语句模板的调用次数、耗时分位与扫过行数，变更后在相同时间窗口重新采集，做同比对照。只看均值容易被调用量变化掩盖，分位值与单次扫过行数更能反映真实改善程度。

长期维护还要防止回退。业务迭代会不断引入新语句，若没有守门机制，治理成果几个月就会被稀释。可行做法是在测试环境接入语句检查，对全表检索、无索引关联、超大结果集等模式给出阻断或告警，把问题拦在上线之前。配合定期的索引使用统计复盘，数据库性能才能维持在稳定区间，而不是在每次大促前临时抢修，那种救火式优化既耗人力又难以沉淀经验。容量视角同样不能缺席。表规模增长会让原本合适的计划逐渐失效，一个百万行表上的全表检索无关痛痒，同样的语句在亿行表上就是灾难。建议对核心表设置行数与体积的增长告警，达到阈值时主动复核相关语句，把优化动作提前到问题暴露之前，这比等待告警响起再处理要从容得多。

结语：执行计划分析的价值在于把模糊的性能抱怨变成可定位的具体节点。统计信息保证优化器判断有依据，索引设计保证读写成本可控，慢查询聚类保证精力用在收益最大的地方。三者加上变更评审与效果回归，才构成能够长期运转的治理体系。