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