性能调优概述

本文档介绍了 YMatrix 中的性能调优思路，可以涵盖服务器系统资源调优、数据库资源调优及 SQL 调优。

1 为什么要进行性能调优？

性能调优是一个综合性很强且不能忽视的问题。

进行性能调优一般有两个原因：

一个前提：

根据性能监控的数据及其他需求信息描述目前的性能瓶颈或性能需求。

一个好的问题描述应该涵盖上下文，清晰地描述问题现象，不宜过长，通常包含但不限于以下信息：

较优的描述例如：使用 YMatrix 5.0 版本图形化界面自带的写入工具，入数 280W 条，30 次测试以后，延时从 30 秒增长到了 1 分钟，性能下降近 1 倍。

较劣的描述例如：使用图形化界面生成测试数据越来越慢。

不同业务场景优化目标不同。例如对于一个车联网的时序场景，可能会有如下优化目标：提高明细查询中涉及的聚集查询、关联查询的性能等。而对于一个金融核心的 OLTP 系统，优化目标可能是：降低交易的长尾延迟等。

一个好的优化目标定义，应该是量化的，例如：

而不是：

YMatrix 推荐收集但不限于以下信息以备分析使用：

基于收集到的信息，定位或者推测性能瓶颈即可，可能需要多次收集相关信息才能最终定位问题。详细思路见性能调优。

注意！
沟通协作是快速分析原因的诀窍之一。

通过分析确定性能瓶颈后，根据实际情况提出低成本、低风险、并能获得最大的收益的优化方案。

需要注意的是，即使某个方案针对最大瓶颈点的优化潜在收益最大，也需要同时评估该方案的风险和成本。通常，YMatrix 建议的调优顺序如下，成本/风险从低至高：

硬件
通过配置测试和基准测试可以很快地确定硬件更新所带来的效果。
查询 SQL 语句
使用 ANALYZE 语句重新收集数该表统计信息；或通过对查询计划的分析，修改 SQL 语句，以降低逻辑复杂度和成本开销。
系统配置参数
通过调整与该查询相关的系统配置参数得到性能提升。需要注意的是，如果即将修改的配置参数为系统级别（System），则必须谨慎分析修改后是否会有不利的全局性影响。
数据模型
在上述方法都无法完成性能调优时，需要考虑对建表 DDL 语句进行一定的调整，由于调整表结构所带来的影响和风险较大，请不到万不得已不要采取该种方法。

注意！
为了避免在业务运行中出现无法修复的性能瓶颈，请对初始设计更加重视，对该场景的数据模型进行科学的规划、分析与测试，确保其正确性。

实施调优的过程通常需要但不限于进行以下工作：

通常，性能调优并不是一次完成的过程，针对同一个性能问题，可能要对 2.3 - 2.7 步骤进行多次循环才能最终得到满意的结果。

因此，需要对调优结果进行直观地评估，并采取以下行动：