開發(fā)使用的注意點(diǎn)
1.分區(qū)表的使用建議
- 業(yè)務(wù)形態(tài)（熱點(diǎn)數(shù)據(jù)打散、歷史數(shù)據(jù)維護(hù)便利性、業(yè)務(wù)SQL的條件形態(tài)（分區(qū)裁剪））审编。
- OB各種分區(qū)類型的設(shè)置要求。
- 大表變分區(qū)表歧匈。
- 分區(qū)鍵的選擇垒酬，分區(qū)鍵必須是主鍵的子集。
- 考慮分區(qū)裁剪、partition wise join優(yōu)化伤溉。
- Range分區(qū)般码，最后一個(gè)不能是maxvalue。
- 分布式事務(wù)乱顾，Leader Binding板祝、Table Group。
- 為了避免寫入放大問題走净，選擇表的自定義主鍵時(shí)券时，不要使用隨機(jī)生成的值，要盡量有序伏伯，比如時(shí)序遞增的橘洞。
- 分區(qū)個(gè)數(shù)：單機(jī)分區(qū)上限（5萬）、單機(jī)租戶允許創(chuàng)建的最大分區(qū)數(shù)量上限（租戶內(nèi)存）说搅、單表分區(qū)數(shù)上限（8192）炸枣。
2.局部索引和全局索引的取舍
- 如果查詢條件里“包含完整的分區(qū)鍵”，使用本地索引是最高效的（分區(qū)裁剪）弄唧。
- 如果需要“不包含完整分區(qū)鍵”的唯一約束适肠，1）使用全局索引；2）使用本地索引候引，且需要索引列上必須帶上表的分區(qū)鍵侯养。
- 其他情況，
- 通常來說澄干，全局索引能為高頻且精準(zhǔn)命中的查詢（比如單記錄查詢）提速并減少IO逛揩；對范圍查詢則不一定哪種索引效果好。
- 不能忽視全局索引在DML語句中引入的額外開銷：數(shù)據(jù)更新時(shí)帶來的跨機(jī)分布式事務(wù)麸俘，事務(wù)的數(shù)據(jù)量越大則分布式事務(wù)越復(fù)雜辩稽。
- 如果數(shù)據(jù)量較大，或者容易出現(xiàn)索引熱點(diǎn)疾掰，可以考慮創(chuàng)建全局分區(qū)索引搂誉。
3.分布式事務(wù)流程及優(yōu)化方法
- 2PC流程用戶感知的commit延遲
- 標(biāo)準(zhǔn)：4次日志延遲 + 2次RPC延遲
- OB：1次日志延遲 + 2次RPC延遲
- 優(yōu)化辦法：
- 盡量避免跨機(jī)分布式事務(wù)徐紧。
- 慎重選擇事務(wù)中的第一條語句静檬，因?yàn)镺BProxy的路由規(guī)則。
- Primary_zone并级、Table Group設(shè)置拂檩。
4.OB Proxy的路由規(guī)則
- proxy parser 在根據(jù)SQL選擇server時(shí)，有以下幾點(diǎn)特殊的邏輯：
- proxy parser只解析Begin/START TRANSACTION/SET 和其他DML語句嘲碧，如果遇到其他單詞開頭的語句稻励，proxy的parser會直接跳過，認(rèn)為該語句不包含表名。
- proxy parser會按照第一條包含實(shí)體表名的stmtement進(jìn)行路由望抽，如果整個(gè)stmtement都不包含表名加矛，則將請求發(fā)送至上一條SQL所發(fā)送的server。
- OB Server會根據(jù)執(zhí)行計(jì)劃的類型煤篙，來告訴proxy是否將請求路由至正確的server斟览，如果路由失敗，proxy會更新location辑奈，當(dāng)前的反饋機(jī)制如下：
- server返回第一條DML的命中情況
- 推薦用法：
3.1 以下幾種情況（select可以等價(jià)替換成update/delete/replace/insert苛茂，下同），proxy能夠?qū)⒄埱蟀l(fā)送至正確的server鸠窗，并且server能夠按照proxy的命中情況進(jìn)行反饋妓羊。
begin; select * from t1; commit;
set @@autocommit = 1; insert into t1 values(); set @@autocommit = 0；
select * from t1; insert into t2 values();
set @@ob_trx_timeout = 10000000; begin; select * from t1; commit;
3.2 以下幾種情況稍计，proxy會將請求發(fā)送至上一個(gè)SQL所使用的server躁绸。
create table t1(id int primary key);create table t2(id int primary key);
- 不推薦用法：
4.1 以下幾種情況（第一個(gè)DML是非實(shí)體表），proxy能夠?qū)⒄埱蟀l(fā)送至正確的server臣嚣，但是server反饋的信息可能不準(zhǔn)涨颜，不建議使用。
select '1'; select * from t1;
select '1' from dual; select * from t1;
4.2 以下幾種情況茧球，proxy可能能夠?qū)⒄埱舐酚芍琳_的server庭瑰，但是server反饋的信息可能不準(zhǔn)確，不建議使用抢埋。
create table t1(id int primary key); insert into t1 values();
4.3 以下幾種情況婶希，proxy會強(qiáng)制將請求路由至上一次使用的server慕匠，server反饋的信息可能不準(zhǔn)確，不建議使用。
show warnings; select * from t1;
show count(\*) errors; select * from t1;
5.大事務(wù)尺寸限制帖池、長事務(wù)
【報(bào)錯(cuò)】
- ERROR 6244(HY000): out of transaction threshold
【原因】
- LSMT結(jié)構(gòu)，批量寫出臟數(shù)據(jù)胳泉。
- 凍結(jié)動作時(shí)不能“轉(zhuǎn)儲未提交事務(wù)”颗胡，需要事務(wù)搬遷到1-freeze_trigger%
【場景】
- 業(yè)務(wù)租戶內(nèi)存配置較低
- 單體大事務(wù)
- 事務(wù)并發(fā)量大
【建議】
- 調(diào)整具體的表結(jié)構(gòu)和調(diào)整業(yè)務(wù)的并發(fā)量
- 數(shù)據(jù)生命周期管理，考慮partition add/drop酷愧，而不是delete
- 調(diào)整業(yè)務(wù)SQL邏輯驾诈，將大段的事務(wù)拆成小段
6.懸掛、長事務(wù)和超時(shí)保護(hù)機(jī)制
【概念】
- 懸掛事務(wù)
- 長事務(wù)
【危害】
- 持有memtablede的ref溶浴，memstore內(nèi)存爆炸
【建議】
- 謹(jǐn)慎的timeout設(shè)置
- 查詢超時(shí)系統(tǒng)變量：ob_query_timeout（默認(rèn)10s）
- 事務(wù)超時(shí)參數(shù)：ob_trx_timeout（默認(rèn)100s）
- 事務(wù)空閑超時(shí)：ob_trx_idle_timeout（默認(rèn)120s）
- 事務(wù)及時(shí)提交
【監(jiān)控】
select * from _all_virtual_trans_stat where (now() - ctx_create_time) > 1000;
7.Buffer表的使用建議
【業(yè)務(wù)形態(tài)】
- 會在短時(shí)間內(nèi) 寫入-修改-刪除
【問題】
- fuse流程時(shí) data scan 時(shí)鏈路變長乍迄，SQL變慢
【原因】
- LSTM的變更鏈路
【常見的Mitigation】
- OB：memtable row purge
- OB：針對buffer表使用特殊的轉(zhuǎn)儲策略：fast freeze
- 手工major freeze以消除多版本，減少層級
- CBO統(tǒng)計(jì)信息不準(zhǔn)確導(dǎo)致的sql plan change士败、outline綁定
8.適配大查詢隔離參數(shù)
【為什么要適配】
- 每個(gè)租戶分配一定比例的資源來處理大查詢
【對應(yīng)參數(shù)】
- large_query_threshold(default 100ms)
- large_query_worker_percentage(30)
【適配點(diǎn)】
- 這些參數(shù)需要精細(xì)化控制闯两。
- 這是因?yàn)?租戶級的活躍線程數(shù)是一個(gè)容量資源，線程數(shù)量是固定的。
9.業(yè)務(wù)冪等重試邏輯
【報(bào)錯(cuò)】
- -6225: ERROR 4012(25000):OB-4012:Transaction result is unknown
- Communication link failure during commit().Transaction resolution unknown.
【場景】
- 切主時(shí)的事務(wù)搬遷
- 網(wǎng)絡(luò)RPC隊(duì)列堆積漾狼、網(wǎng)絡(luò)傳輸慢
- 2PC過程中協(xié)調(diào)者宕機(jī)
- 事務(wù)超時(shí)參數(shù) ob_trx_timeout （默認(rèn)100s）/ob_trx_idle_timeout（默認(rèn)120s）
【建議】
- 業(yè)務(wù)適配冪等重試邏輯
- 監(jiān)控
10.定時(shí)合并任務(wù)重慢、Noisy Neighbor問題
- 合并任務(wù)都做了什么？
- Compaction
- 數(shù)據(jù)壓縮
- 數(shù)據(jù)校驗(yàn)
- 漸進(jìn)schema變更
- 統(tǒng)計(jì)信息收集
- 定時(shí)合并任務(wù)默認(rèn)時(shí)間為 02:00
- Noisy Neighbor問題
11.自增列逊躁、無主鍵表伤锚、Sequence
- 自增列
- 可以指定自增起始值、自增步長志衣、自增列緩存大小
- MySQL mode:
create table `test`( `id` int(32) not null auto_increment comment '自增id', ……) - 連續(xù)性：跳變問題
- 無主鍵表
- 基于自增列方式生成的隱藏列
- sync_value同步調(diào)優(yōu)by autoinc_cache_refresh_interval
- 建議建表時(shí)為表設(shè)計(jì)主鍵或者唯一鍵
- 不支持后加主鍵
- Sequence
- 默認(rèn)使用 cache + noorder 屯援，性能考慮
- Cache Size：單機(jī)TPS=100時(shí)候，cache size 建議
100*60*60=360000
