摘要：数据库调优是项复杂的工作，需要多方面的知识。本文简单介绍了GaussDB数据库性能调优的策略和问题分析方法。

调优概述

好的性能主要来自好的设计，如果业务流程和表设计的不合理，单纯优化SQL来提升性能常常会事倍功半。数据库调优是项复杂的工作，需要多方面的知识。虽然数据库的优化器越来越智能了，但是如果没有很好的理论基础和实践经验，仍然可能设计出性能很差的应用。

如果希望良好使用数据库，需要掌握以下理论知识：

● 数据库原理：掌握数据库基本原理，理解数据库范式，熟练掌握SQL的用法。
● 执行计划：能看懂执行计划，理解每种扫描、连接方式的代价。
● 数据库特性：包括分区、触发器、存储过程、锁等特性

调优策略

实现一个业务目标，可能有很多种设计方案；实现一个SQL功能，也可能有很多种实现方式。数据库设计和性能优化的核心就是让数据库少干活即少扫描数据，绝大部分的SQL性能优化都是为了降低数据库的工作量。

那么如何降低数据库的工作量呢？

● 从业务流程上考虑：避免不必要的数据传输、数据交互以及产生的中间结果。
● 从表设计上考虑：避免不必要的表的关联，通过合适的索引、分区快速定位到目标数据。
● 从SQL上考虑：选择合适的执行计划，高效的访问数据。

数据查询

● 索引
对于GaussDB T数据库来说，绝大部分的SQL是查询，那么用好索引非常关键，绝大部分的SQL问题是由于索引的设计不合理导致的。
– 首先，索引的设计一定是基于业务需要的，而不是随意添加索引。如果索引设计逻辑较为复杂，那么可能是表的设计不合理或者需要优化业务方案。
– 其次，组合索引的设计非常重要，也很常用，并不是将列字段随意组合作为索引，组合索引中列的顺序非常关键。
– 后，索引大的特点是有序性，常常需要利用索引来规避排序，尤其是在分页查询中，这也是索引应用的难点。

● 分区表
除了索引外，分区表是GaussDB T数据库重要的特性。绝大部分的数据库应用都要考虑分区，合理的使用分区对性能有极大的提升。

很多开发人员只考虑实现功能，不考虑性能，写出来的SQL非常复杂，读懂这样的代码比较困难。建议不要让SQL实现过于复杂的功能。SQL的复杂度随着关联表的增加不是线性增长的，而是接近指数级增长的。对于一个过于复杂的SQL，看懂业务逻辑和执行计划是非常困难的，维护这样的代码是非常痛苦的。

建议：
– 关联的表一般不要超过三个，避免关联不必要的表。
– 建议使用连接查询，减少不必要的嵌套和子查询。
– 避免使用复杂视图。

性能调优

性能问题往往表现为某个业务慢，需要分析性能瓶颈是什么。有可能是配置引起的，例如redo配置小了导致redo追尾或者内存参数配置小了导致IO很高。分析性能瓶颈常用的工具是WSR报告，通过WSR的Top等待事件可以看出数据库的哪个阶段的时间消耗较多。等待事件是非常重要的信息，需要了解每种等待事件触发的原因以及调优方法随着数据库功能的不断完善，等待事件会逐步细化，这样通过等待事件可以非常容易找到性能瓶颈。

如果是配置问题，直接修改配置即可。大部分的性能问题是SQL造成的，需要进一步定位关键SQL。绝大部分情况下，WSR报告可以找到对性能影响大的SQL。因此需要对单条SQL进行分析，理解执行计划每一步的含义和代价。这一步是难的地方，需要具备大量的知识和经验。

单SQL存在性能问题，可能有很多原因：

● SQL写法有问题，例如产生了笛卡尔积、类型不匹配导致隐式转换，改写SQL即可。
● 统计信息有问题，需要重新收集，对于变化非常快的表需要业务主动触发收集或者用提示固定执行计划。
● 执行计划有问题，缺少合适的索引，通过增加索引可以解决该问题。
● 固定的执行计划有问题，由于使用提示导致使用了RBO优化器，有可能不是优的执行计划，需要增加或改写提示人工调整执行计划，对于复杂的SQL难度较大。
● 优化器bug，生成了不好的执行计划，需要改写SQL规避或者等待切换新版本。

以上是常见的分析方法，SQL除了执行计划问题，还可能出现其他性能问题，例如锁等待的问题、热块问题、commit过于频繁的问题等等这些信息在WSR报告中可以显示，同时可以通过一些性能视图作为辅助的定位工具。