用户 SQL 写法未遵循 OceanBase 数据库开发规范

用户 SQL 的写法对 SQL 的执行性能有决定性的作用。在使用过程中，用户应尽量遵循 OceanBase 数据库开发规范的要求。

代价模型缺陷导致的执行计划选择错误

OceanBase 数据库内建的代价模型是服务器的固有逻辑，最佳的执行计划依赖此代价模型。因此，一旦出现由代价模型导致的计划选择错误，用户只能通过执行计划绑定来确保选择“正确”的执行计划。

数据统计信息不准确

查询优化过程依赖数据统计信息的准确性，OceanBase 数据库的优化器默认会在数据合并过程中收集一些统计信息，当用对数据进行了大量修改时，可能会导致统计信息落后于真实数据的特征，用户可以通过发起每日合并，主动更新统计信息。

除了优化器收集的统计信息以外，优化器还会根据查询条件对存储层进行采样，用以后续的优化选择。OceanBase 数据库目前仅支持对本地存储进行采样，对于数据分区在远程节点上的情况，只能使用默认收集的统计信息进行代价估计，可能会引入代价偏差。

数据库物理设计降低查询性能

查询的性能很大程度上取决于数据库的物理设计，包括所访问对象的 schema 信息等。例如，对于二级索引，如果所需的投影列没有包括在索引列之中，则需要使用回表的机制访问主表，查询的代价会增加很多。此时，可以考虑将用户的投影列加入到索引列中，构成所谓的“覆盖索引”，避免回表访问。

系统负载影响单条 SQL 的响应时间

系统的整体负载除了会影响系统的整体吞吐量，也会引起单条 SQL 的响应时间变化。OceanBase 数据库的 SQL 引擎采用队列模型，针对用户请求，如果可用线程全部被占用，则新的请求需要在请求队列中排队，直到某个线程完成当前请求。请求在队列中的排队时间可以在 (g)v$sql_audit 中看到。

客户端路由与服务器之间出现路由反馈逻辑错误

OBProxy 的一个主要功能是将 SQL 查询路由到恰当的服务器节点。具体来说，如果用户查询没有指定使用弱一致性读属性，Proxy 需要将其路由到所涉及的表（或具体分区）的主节点上，以避免服务器节点之前的二次转发；否则，Proxy 会根据预先设置好的规则将其转发到恰当的节点。

由于 Proxy 与服务器之间采用松耦合的方式，Proxy 上缓存的数据物理分布信息刷新可能不及时，导致错误的路由选择。可能导致路由信息变化的场景有：

• 网络不稳导致服务器间重新选主

• 由服务器上下线、轮转合并等导致的重新选主

• 负载均衡导致重新选主

当在 SQL audit 或执行计划缓存中发现有大量远程执行时，需要考虑是否与上述场景吻合。客户端与服务器之间有路由反馈逻辑，一旦发生错误，客户端会主动刷新数据物理分布信息，随后路由的选择也将恢复正常。