排除优化器自身的 bug 原因，为了使某些 SQL 的执行时间或资源消耗符合预期，一般需要用户对数据库的设置做相应的修改，常见的手段包括：

    • 修改系统配置项或系统变量
    • 对数据 schema 进行修改，包括创建数据分区、创建二级索引等
    • 修改用户SQL，包括对SQL做等价改写、增加 hint 等
    • 调整并行查询的并行度

    一条SQL从发送到数据开始执行，到返回结果给用户，会经历队列等待、plan cache 查询、计划优化（如果计划缓存不命中）、计划执行、返回结果等过程。当发现SQL的响应时间增加时，第一步应该明确具体是哪部分的耗时增加，此时采用的一般手段包括 SQL Trace、查询 SQL Audit 表、查看慢查询日志等。只有明确了具体耗时在哪里，才能有针对性的进一步分析问题的根源。

    针对单条 SQL 的执行计划性能调优又可以分为单表访问和多表访问两种场景。

    单表访问场景

    对单表访问SQL来说，需要重点关注的问题包括：

    • 访问路径是否开启索引扫描

    排序或聚合往往都是比较耗时的操作。优化器为了尽可能的降低执行时间，在有合适索引可用时，考虑直接使用索引的顺序以避免额外的排序操作，同理，用户也可以根据经常需要排序的列，创建合适的索引，以避免不必要的排序操作。

    • 分区裁剪是否正确

    分区裁剪是分区表优化的重要手段，一般来说，只要用户提供了合适的分区条件，优化器会自动跳过无需访问的分区。

    • 是否需要调整查询的并行度

    提高查询的并行度可以使用更多资源的代价获取单条 SQL 查询的性能提升，当查询牵涉到的数据量较大，分区数目较多时，可以通过提高并行度的方式加快执行时间。

    多表访问场景

    针对多表访问的 SQL，不仅要关注单表的 SQL 调优的重点问题，还需要关注多表间的连接问题，需要分析的点包括：

    • 连接顺序
    • 连接算法
    • 跨机或并行连接的数据再分布方式

    针对吞吐量的性能调优

    吞吐量性能调优可考虑以下几个方面：

    • 优化慢 SQL

    大量慢 SQL 请求会消耗大量的资源，导致整体吞吐量上不去，可按如下步骤处理：

    1. 通过 OCP 的 TOP SQL 功能或利用 Plan Cache 视图查询耗时为 TOP N 的 SQL。
    • 均衡 SQL 的请求流量资源

    在多机环境下，我们需要尽量将所有机器资源都能使用到，因此需要考虑流量是否均衡，可以，影响均衡的因素主要有：

    • ob_read_consistency 如何设置
    • primary zone 如何设置
    • proxy 或 java 客户端路由策略相关设置

    • 业务热点查询分区是否均衡

    大量分布式计划时一般都设置了弱读，资源消耗主要在子计划的 RPC 请求上，在 SQL 请求均衡的情况下，通过sql_audit 可查看子计划 RPC 请求是否均衡，影响这些子计划请求是否均匀的主要因素有：

    • observer 内部路由策略相关设置
    • 业务热点查询的分区是否均衡