最佳實踐概述
場景描述
概(gai)述(shu)：分布(bu)式(shi)關(guan)系(xi)型數(shu)據(ju)(ju)(ju)庫(ku)（簡稱DRDS），是一(yi)款分布(bu)式(shi)關(guan)系(xi)型數(shu)據(ju)(ju)(ju)庫(ku)。兼容MySQL協議(yi)，專注于解決(jue)數(shu)據(ju)(ju)(ju)庫(ku)分布(bu)式(shi)擴展問題，突破傳統(tong)數(shu)據(ju)(ju)(ju)庫(ku)的容量和性能瓶(ping)頸(jing)，實現海(hai)量數(shu)據(ju)(ju)(ju)高并(bing)發訪問。
典型行(xing)業：互聯(lian)網企業
適(shi)配場景(jing)：適(shi)用于數(shu)據規模較(jiao)大的場景(jing)
方案優勢
- 自動分庫分表
- 讀寫分離
- 彈性擴容
前提條件
需搭(da)配開通(tong)RDS for MySQL和DRDS等產品
資源規劃
網絡資源規劃
Figure 1 網絡資源規(gui)劃
資源類型 配置項 配置明細 說明 區域 區域 西安2 本最佳實踐全部資源部署在西安2資源池 專有網絡VPC 狀態 新購 云上選擇專有網絡（VPC）以保障安全性。
選擇離原系統公網?IP 近的云上區域減少網絡延遲。
選擇資源豐富、離用戶近的區域保障項目順利實施。
網絡規劃留足可用?IP 數即可。VPC名 vpc-vsfl 網段 192.168.0.0/16
彈性計算資源規劃
Figure 2 彈性計算資源規(gui)劃
資源類型 配置項 配置明細 說明 ECS-（MySQL 服務器） ECS名稱 ecs-bendi 自定義，易理解可識別 規格 通用計算增強型?
?c3.large.2?
?2vCPUs?
?4GiB
本示例中選擇的規格。實際選擇的規格需要結合業務場景選擇，請參考彈性云服務器的實例規格。 操作系統 Windows 2016 - 系統盤 通用型SSD 40GiB -
數據庫資源規劃
資源類型 配置項 配置明細 說明 RDS RDS實例名 rds-8c73 自定義，易理解可識別 數據庫版本 PostgreSQL 12.6 本示例中為單機。實際使用時，為提升業務可靠性，推薦選擇主備RDS實例。 實例類型 單機 - 存儲類型 SSD - 可用區 可用區1 本示例中未單機，實際業務場景推薦選擇主備RDS實例，此時建議將兩個實例創建在不同的可用區，提升業務可靠性。 規格 2 vCPUs | 4 GB - DRDS RDS實例名 Drds-53c1 自定義，易理解可識別 數據庫版本 DRDS 選擇邏輯庫總分片數為2，可根據需要按需進行分片 實例類型 雙節點 最大可支持32節點 配置 8C16G
方案正文
insert操作
insert寫法規范
- 不建議逐條insert，推薦使用insert into values (),()..();語法。
- MySQL的JDBC連接的url中要加rewriteBatchedStatements參數，并保證5.1.13以上版本的驅動，才能實現批量插入。MySQL
JDBC驅動在默認情況下會無視executeBatch()語句，把預計批量執行的一組sql語句拆散，一條一條地發給MySQL數據庫，批量插入實際上是單條插入，直接造成較低的性能。只有把rewriteBatchedStatements參數置為true,
驅動才會批量執行SQL。另外這個選項對INSERT/UPDATE/DELETE操作都有效。
- 拆分字段的值：不建議使用函數、表達式、子查詢等，推薦使用常量值。
- 普通字段的值：不建議使用子查詢，推薦使用常量、函數、表達式。
大批量數據導入
推(tui)薦(jian)使(shi)用loaddata local infile來實(shi)現大批量(liang)數(shu)據導入。
數據遷移場景
建(jian)議使(shi)用mysqldump導出sql文件，再使(shi)用mysql source命令導入。
auto_increment字段
- DRDS使用Sequence來實現auto_increment語義，并保證全局唯一。
- 賦值：若使用auto_increment字段，建議不要在values子句中賦值，否則容易造成主鍵沖突。如果在values中賦了值，建議使用alter sequence語句更改。
- 步長：auto_increment字段步長建議不要設置成1，會導致性能低下。默認設置成1000。
update與delete操作
普通更新
- 進行update/delete操作時，where條件建議帶上拆分字段；
- 無法帶上拆分字段的場景，建議控制并發度，控制更新/刪除涉及的數據條數。建議先用select查出相應的數據，double check確保數據范圍無誤后再實行update/delete操作。
拆分字段更新
- 條數限制：DRDS拆分字段更新有數據量限制，一般不能超過10000條數據，數據量越少越好。若超過10000條數據，建議用改重建表的方式來做，或者是拆分成多次update操作來等價實現。
- 操作的時機：建議選擇在業務低谷期做。
關聯操作
不建(jian)議進(jin)(jin)行表關聯(lian)更新、表關聯(lian)刪除操作(zuo)，即不建(jian)議進(jin)(jin)行多(duo)張表同時(shi)進(jin)(jin)行update/delete操作(zuo)。
- 子查詢及limit操作
不(bu)建議update/delete語(yu)句中含(han)有子查(cha)詢。不(bu)建議update/delete語(yu)句中含(han)有limit或order by limit語(yu)句。
select操作
- Order by 及 Limit函數
- "order by limit offset, count"場景，禁止給offset賦大數值，即禁止深度翻頁。
Group by函數
- 不建議select_list部分含有非group by列。
- 不支持不可下推的group_concat聚合函數內含有order by子句。
- 不建議distinct、group by字段多于3項。
- 不建議join、或者子查詢操作之后含有group by操作
- 不建議使用count(distinct ),sum(distinct )操作。
Join函數
- select場景，建議join條件是每個表的拆分字段或使用廣播表，或者是驅動表是一個小表（inner/left join驅動表是左表，right join驅動表是右表）。
- 不建議兩個大表直接進行join操作。
- 不建議join on condition中含有非等值操作。
- 如遇到臨時表超限（Temp table limit exceeded）報錯，說明JOIN中間數據產生了臨時表且超限，建議進行SQL調優。
- 不建議5張表以上進行join操作。
- join查詢操作建議不要開啟事務。
- 不建議在事務中進行join查詢，開啟事務會影響DRDS對join算法的選擇，無法使用最高效的算法。
子查詢
- 不建議子查詢包含在OR表達式中，或者是子查詢的關聯條件包含在OR表達式中
- 不建議使用含有limit的標量子查詢，如 select (select x from t2 where t2.id= t.id limit 1),a,b from t。
- 如果子查詢和主表都路由到同一分片，建議在SQL前加/+db=xxx/來精準路由。
- 不建議子查詢內部含有join語句。
- 不建議寫嵌套子查詢。
- 不建議ROW表達式跟子查詢做比較操作，如 select * from t where (a,b,c)=(select x,y,z from t2 where …)。
- 不建議select_list里面含有超過2個以上的子查詢 。
DDL
DDL執行時機
- 對已有表進行DDL操作時建議放在業務低峰期進行。
分片數
- 創建新拆分表時建議結合實際數據量進行合理預估，總分片數滿足需求即可。不建議使用超出實際需求的分片數，拆分表分片數并非越多越好
高危DDL
- 進行高危DDL時請仔細校驗SQL后謹慎操作，如DROP TABLE, TRUNCATE TABLE等操作。
DDL失敗修復
- DDL命令如遇報錯，可以使用"check
table 表名"命令對各個分片表結構進行校驗，識別出失敗的分片進行針對性修復。如ALTER
TABLE命令遭遇失敗可以在命令前添加/*+allow_alter_rerun=true/，開啟ALTER語句的冪等可重入執行后重試，直到check
table 命令提示各個分片表結構達到一致則可認為執行成功。
MDL鎖導致執行DDL報錯
- 背景：為保證DDL的可用性，DRDS內部在執行DDL前會檢查底層RDS相關表是否存在MDL鎖。 若存在MDL鎖,，則DDL會提前報錯退出。
- 可能出現的問題：若系統中存在慢SQL，執行時間為幾分鐘不等，那么可能被MDL鎖所阻攔，無法執行DDL。
- 解決方案1：在DRDS控制臺提高參數“ddl_precheck_mdl_threshold_time”的大小, 如提高到30分鐘(1800秒)。
- 解決方案2：執行show
metadata lock查看是否因為持有慢事務的MDL鎖阻塞了DDL的執行。若存在阻塞, 可以使用kill physical
threadId@host:port 來關閉底層慢事務。配合/+allow_alter_rerun=true/的hint, 以及check
table來查看和執行，直到DDL徹底執行完。
DDL長時間卡死
- 在業務低峰期執行DDL時如果遇到長時間卡死情況，請另開會話執行xa recover命令查看是否有慢事務存在，如存在慢事務掛起請及時聯系值班人員解決。
