数据库性能优化是一个永恒的话题，DBA们似乎永远在讨论它。究其原因，性能问题是最终用户抱怨最多的一类技术问题——没有之一。
如果DBA能迅速解决性能瓶颈，他们就是团队里的英雄；如果迟迟无法定位问题，再好的架构设计也可能被用户否定。
那么问题来了：面对一个性能不佳的数据库，应该优先关注什么？
我认为有两个关键要点是任何性能优化工作的起点。
一、保持统计信息最新
1.1 为什么统计信息如此重要？
没有统计信息，关系型优化器就无法做出准确的执行计划决策。数据库统计信息提供了关于数据状态和组织结构的情报，优化器利用这些情报来判断如何最高效地获取数据。
可以把统计信息理解为数据库的人口普查数据，没有它，优化器就像一个盲人，只能随机选择执行路径。
1.2 统计信息的核心组成
| 统计信息类型 | 包含内容 | 对优化器的影响 |
|---|---|---|
| 表级统计信息 | 总行数、压缩率、总数据块数 | 估算全表扫描成本 |
| 列级统计信息 | 离散值数量、数据分布直方图 | 判断谓词选择性 |
| 表空间统计信息 | 活动页数、聚簇率 | 评估I/O成本 |
| 索引统计信息 | 叶子页数量、索引层级、离散键值数 | 判断索引扫描成本 |
1.3 统计信息的收集时机
统计信息通过特定命令生成——不同数据库有不同语法：
DB2：RUNSTATS
SQL Server：UPDATE STATISTICS
Oracle：GATHER_TABLE_STATS
MySQL：ANALYZE TABLE
关键原则是：统计信息必须在数据发生显著变化后及时更新。
以下场景建议立即收集统计信息：
批量数据导入/导出后（数据量变化超过10%）
大量数据删除后
表结构变更后（如新增索引、修改列类型）
定期的维护窗口（如每周/每月）
避坑提醒：统计信息过期是导致SQL突然变慢的最常见原因之一。原本运行良好的查询，在数据量增长后突然变慢，大概率是统计信息没有及时更新。
1.4 统计信息过期的典型症状
| 现象 | 可能的原因 |
|---|---|
| 执行计划突然变化 | 统计信息未反映真实数据分布 |
| 查询耗时从毫秒级变秒级 | 优化器选择了错误的连接顺序或访问路径 |
| 同一个查询有时快有时慢 | 统计信息不稳定或采样率过低 |
二、构建合适的索引
2.1 索引设计的核心原则
与收集最新统计信息同等重要的是为表创建正确的索引。索引是提升查询性能最直接的手段，但也需要谨慎设计，索引并非越多越好。
一个简单的查询示例：
SELECT LASTNAME, SALARY FROM EMP WHERE EMPNO = '000010' AND DEPTNO = 'D01';2.2 索引候选方案评估
对于这个查询，可以创建多种索引：
| 索引方案 | 索引列 | 适用性分析 |
|---|---|---|
| Index1 | (EMPNO) | 可快速定位EMPNO匹配的行，但仍需在结果中过滤DEPTNO |
| Index2 | (DEPTNO) | 可快速定位DEPTNO匹配的行，但仍需过滤EMPNO |
| Index3 | (EMPNO, DEPTNO) | 最佳：可直接定位同时满足两个条件的行 |
为什么Index3是最佳选择？
Index3允许DBMS通过一次索引查找定位到同时满足EMPNO='000010'和DEPTNO='D01'的精确行，无需额外过滤。关键细节是：索引中列的顺序至关重要。在此场景下，EMPNO应放在首位（等值查询），DEPTNO放在第二位。
2.3 索引设计的权衡因素
权衡一：查询性能 vs 修改性能
DBMS必须自动维护每个创建的索引：
每插入一行 → 更新所有索引
每删除一行 → 更新所有索引
更新索引列 → 更新对应索引
因此，索引越多，插入、删除、更新的速度越慢。在OLTP环境中，需要在这两者之间找到平衡点。
权衡二：是否复用现有索引
如果EMPNO或DEPTNO上已有单列索引，某些DBMS可以同时使用两个单列索引（通过Bitmap Index Merge或Index Join）来满足查询，不一定需要新建复合索引。
决策依据：查询的重要性。CEO每天运行的查询，值得专门创建最佳索引；相比之下，普通职员的临时查询，使用现有索引即可。
权衡三：索引重载
如果SQL所需的所有数据都包含在索引中，DBMS可以仅通过索引满足请求，无需访问表数据。
之前查询中，我们只查询LASTNAME和SALARY，而EMPNO和DEPTNO已经是查询条件：
-- 创建覆盖索引 CREATE INDEX idx_emp_covering ON EMP(EMPNO, DEPTNO, LASTNAME, SALARY);现在，DBMS可以仅通过索引返回所有数据，再不触碰EMP表。技术术语叫仅索引访问。
试图让每个查询都实现仅索引访问既不现实也不明智。应保留此技术给特别重要或频繁执行的SQL语句。
2.4 索引设计速查表
| 场景 | 推荐策略 | 注意事项 |
|---|---|---|
| 等值查询（=） | 将等值列放在索引前列 | 区分度高的列优先 |
| 范围查询（>、<、BETWEEN） | 范围列放在等值列之后 | 范围列之后的其他列无法利用索引 |
| ORDER BY | 索引列顺序与ORDER BY一致 | 考虑升降序匹配 |
| 高频修改的表 | 控制索引数量（建议≤5个） | 每个索引都会拖慢写操作 |
| 重要查询 | 考虑覆盖索引 | 平衡存储成本与查询性能 |
三、统计信息与索引的协同作用
统计信息和索引不是孤立工作的——它们之间存在紧密的协同关系：
| 场景 | 统计信息的作用 | 索引的作用 |
|---|---|---|
| 优化器评估索引扫描成本 | 提供索引统计信息（叶子页数、层级、离散键值） | 提供数据结构支持 |
| 判断是否使用索引 | 提供列统计信息（数据分布、选择性） | 提供访问路径 |
| 评估连接顺序 | 提供表大小、行数估计 | 提供连接键索引 |
协同工作的最佳实践：
创建索引后立即更新统计信息：让优化器能评估新索引的价值
定期更新统计信息：确保优化器掌握最新数据分布
监控索引使用情况：删除从未被使用的索引，减少维护开销
四、总结
如果您是数据库性能管理的初学者，请务必从本文介绍的两个核心要点开始：
| 优先级 | 优化要点 | 核心任务 | 预期收益 |
|---|---|---|---|
| 第一 | 统计信息管理 | 确保统计信息最新、准确 | 优化器能做出正确的执行计划决策 |
| 第二 | 索引设计 | 为重要查询创建合适索引 | 显著减少数据扫描量 |
但请记住，我们对这两个领域的探讨仅是冰山一角。统计信息收集策略（采样率、直方图精度）和索引设计方法论（复合索引列顺序、覆盖索引的使用场景）都值得深入钻研。
即使是资深DBA，重新审视这些问题也绝无坏处，新的数据库版本可能引入你尚未使用过的特性，或者巩固已有的知识体系。
最后，一个经验之谈：
当你遇到数据库性能问题时，不要急于调优SQL。先检查统计信息是否最新，再确认索引设计是否合理。80%的性能问题，答案都在这里。
