OceanBase SQL 調(diào)優(yōu)常見問題

用戶 SQL 寫法未遵循 OceanBase 數(shù)據(jù)庫開發(fā)規(guī)范

用戶 SQL 的寫法對 SQL 的執(zhí)行性能有決定性的作用。在使用過程中，用戶應盡量遵循 OceanBase 數(shù)據(jù)庫開發(fā)規(guī)范的要求。

代價模型缺陷導致的執(zhí)行計劃選擇錯誤

OceanBase 數(shù)據(jù)庫內(nèi)建的代價模型是服務器的固有邏輯，最佳的執(zhí)行計劃依賴此代價模型。因此，一旦出現(xiàn)由代價模型導致的計劃選擇錯誤，用戶只能通過執(zhí)行計劃綁定來確保選擇“正確”的執(zhí)行計劃。

數(shù)據(jù)統(tǒng)計信息不準確

查詢優(yōu)化過程依賴數(shù)據(jù)統(tǒng)計信息的準確性，OceanBase 數(shù)據(jù)庫的優(yōu)化器默認會在數(shù)據(jù)合并過程中收集一些統(tǒng)計信息，當用對數(shù)據(jù)進行了大量修改時，可能會導致統(tǒng)計信息落后于真實數(shù)據(jù)的特征，用戶可以通過發(fā)起每日合并，主動更新統(tǒng)計信息。

除了優(yōu)化器收集的統(tǒng)計信息以外，優(yōu)化器還會根據(jù)查詢條件對存儲層進行采樣，用以后續(xù)的優(yōu)化選擇。OceanBase 數(shù)據(jù)庫目前僅支持對本地存儲進行采樣，對于數(shù)據(jù)分區(qū)在遠程節(jié)點上的情況，只能使用默認收集的統(tǒng)計信息進行代價估計，可能會引入代價偏差。

數(shù)據(jù)庫物理設計降低查詢性能

查詢的性能很大程度上取決于數(shù)據(jù)庫的物理設計，包括所訪問對象的 schema 信息等。例如，對于二級索引，如果所需的投影列沒有包括在索引列之中，則需要使用回表的機制訪問主表，查詢的代價會增加很多。此時，可以考慮將用戶的投影列加入到索引列中，構成所謂的“覆蓋索引”，避免回表訪問。

系統(tǒng)負載影響單條 SQL 的響應時間

系統(tǒng)的整體負載除了會影響系統(tǒng)的整體吞吐量，也會引起單條 SQL 的響應時間變化。OceanBase 數(shù)據(jù)庫的 SQL 引擎采用隊列模型，針對用戶請求，如果可用線程全部被占用，則新的請求需要在請求隊列中排隊，直到某個線程完成當前請求。請求在隊列中的排隊時間可以在 (g)v$sql_audit 中看到。

客戶端路由與服務器之間出現(xiàn)路由反饋邏輯錯誤

OBProxy 的一個主要功能是將 SQL 查詢路由到恰當?shù)姆掌鞴?jié)點。具體來說，如果用戶查詢沒有指定使用弱一致性讀屬性，Proxy 需要將其路由到所涉及的表（或具體分區(qū)）的主節(jié)點上，以避免服務器節(jié)點之前的二次轉發(fā)；否則，Proxy 會根據(jù)預先設置好的規(guī)則將其轉發(fā)到恰當?shù)墓?jié)點。

由于 Proxy 與服務器之間采用松耦合的方式，Proxy 上緩存的數(shù)據(jù)物理分布信息刷新可能不及時，導致錯誤的路由選擇?？赡軐е侣酚尚畔⒆兓膱鼍坝校?/p>

• 網(wǎng)絡不穩(wěn)導致服務器間重新選主

• 由服務器上下線、輪轉合并等導致的重新選主

• 負載均衡導致重新選主

當在 SQL audit 或執(zhí)行計劃緩存中發(fā)現(xiàn)有大量遠程執(zhí)行時，需要考慮是否與上述場景吻合。客戶端與服務器之間有路由反饋邏輯，一旦發(fā)生錯誤，客戶端會主動刷新數(shù)據(jù)物理分布信息，隨后路由的選擇也將恢復正常。