開發規范
更新時間 2025-06-10 11:18:20
最近更新時間: 2025-06-10 11:18:20
分享文章
本頁介紹了分布式融合數據庫 HTAP 的一些基本開發規范。
對象命名規范
- 數據庫、表、索引、用戶等命名建議使用有實際含義的小寫英文單詞或者和下劃線的組合。
- 避免使用分布式融合數據庫HTAP的保留字，例如："join"、"range"、"limit" 等。
- 表名不推薦超過32個字符，須見名知意，匹配查找表名時不區分大小寫。
- 字段名不推薦超過32個字符，須見名知意，建議添加注釋。
- 建議多單詞組成的字段名，使用能代表意義的縮寫作為索引。
表設計規范
- 表需要有主鍵或者非空唯一索引，以便兼容周邊復制工具。
- 業務表使用自增主鍵時，字段類型推薦使用 bigint unsigned。
- 出于性能考慮，盡量避免存儲超寬表，數據長度過大的字段最好拆到獨立的表存儲，建議表字段數不超過 60 個，建議單行的總數據大小不要超過 64K，單行的總數據大小強制不超過 6 MB。
- 不推薦使用復雜的數據類型，如 blob 或者 json。
- 進行 join 的關聯字段，數據類型保證一致，避免隱式轉換。
- 不能以范式作為唯一標準或者指導，在設計過程中，需要從實際需求出發，以性能提升為根本目標。為了提升性能減少表關聯，可以適當保存冗余數據做反范式設計。
- 表對象的設計請注意單個 Table 的限制。Columns 的最大限制可通過 table-column-count-limit 修改；Indexs 的最大限制可通過 index-limit修改。
字段設計規范
- 所有整數類型的字段推薦只使用 INT 或者 BIGINT。
- 浮點類型推薦使用 DECIMAL 。
- 時間字段使用時間日期類型，不要使用字符串類型存儲。
- 所有需要精確到時間(時分秒)的字段均使用 DATETIME，不要使用 TIMESTAMP 類型。
- 僅當字符數量可能超過 20000 個的時候，才建議使用TEXT類型來存放字符類數據。所有使用 TEXT 類型的字段建議和原表進行分拆，與原表主鍵單獨組成另外一個表進行存放。
- 不建議使用 ENUM、SET 類型，盡量使用 TINYINT 來代替。
索引設計規范
- 選擇區分度大的列建立索引，不在低基數列上建立索引。低基數列如：性別，是否是 XXX。
- 單張表的索引數量控制在 5 個以內，避免索引冗余。
- 索引中的字段數建議不超過 5 個。
- 唯一索引建議由 3 個或更少的字段組成。
- 盡量不要在頻繁更新的列上創建索引。
- 盡可能地將使用頻率高的，經常被點查使用的列排在復合索引靠前的位置，將經常進行范圍查詢的列排在后面。
- 很長的 VARCHAR 字段建立索引時，指定索引長度，沒必要對全字段建立索引，根據實際文本區分度決定索引長度即可， 例如 idx_table_name (name(10))。
- 定期刪除長時間未使用過的索引。
- ORDER BY，GROUP BY，DISTINCT 的字段需要添加在索引的后面，形成覆蓋索引。
- 新的 select, update, delete 上線，都要先執行 explain 命令，觀察執行計劃是否有異常情況發現，以確保索引的正確性。
- 不建議在 where 條件索引列上使用函數，會導致索引失效，如 lower(email)。
- 業務語句中使用 like 模糊匹配時 % 不要放首位，以免導致索引失效，或者使用時結合其他有效的約束條件。
多表關聯查詢規范
- 多表關聯應該顯式使用 join 子句，避免漏掉關聯條件，造成笛卡爾積。
- 嵌套SQL語句應該為不同表指定不同別名。
- 高并發交易場景，單條語句關聯表不超過兩張，使用執行計劃為 IndexJoin 的多表關聯語句，外表建立了正確的條件過濾索引，內表建立了正確的關聯和條件過濾索引。
- 低并發的分析場景，單條語句關聯表不超過 10 張，其中億級表不超過 2 張。
大事務處理規范
- 單個事務的總大小默認不超過 100 MB，最大支持 10 GB，實際的單個事務大小限制還取決于服務器剩余可用內存的大小，執行事務時計算節點進程的內存消耗大約是事務大小的 6 倍以上。
- 由于執行事務時計算節點進程的內存消耗大約是事務大小的 6 倍以上，事務設置過大，或者 Batch 過高，可能導致計算節點進程 OOM，需要評估好內存容量。
- 為了使性能達到最優，需要對大事務按某個業務維度進行拆分，每 100～500 行提交一個事務。
防范寫入熱點創建規范
- 對于寫入量非常大的表，應當通過應用性能壓測等方法在測試環境模擬表的熱點情況。
- 通過以下三種手段進行配置，規避表的主鍵寫入熱點。
- 避免連續自增主鍵的設計，建議采用雪花算法生成 UUID 主鍵。
- 主鍵是非整數的表或者啟用 alt-primarykey=true 配置后創建的所有表，使用 SHARD_ROW_ID_BITS 語法創建基于 rowid 的分片方案，例如：CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4 或 ALTER TABLE t SHARD_ROW_ID_BITS = 4。
- 創建按照 Hash 或 Range 分區表避免熱點。
數據建模規范
- 存儲模型選擇策略
| 存儲類型 | 物理特性 | 適用場景 | 禁用場景 |
|---|---|---|---|
| 行存 | 數據按行連續存儲 | 高頻點查（SELECT * FROM WHERE id=123）事務型INSERT/UPDATE |
全表掃描分析查詢 |
| 列存 | 數據按列壓縮存儲 | 聚合計算（SUM(sales) BY region）低更新頻率的寬表查詢 |
高頻單行UPDATE操作 |
| 行列混合 | 熱數據行存+冷數列存 | 需要同時支持實時交易和歷史分析的系統 | 資源極度受限的環境 |
行列共存實現示例 ：
-- 創建表時顯式指定存儲方式
CREATE TABLE orders (
order_id BIGINT PRIMARY KEY, -- 默認行存
customer_id INT,
order_date TIMESTAMP,
total_amount DECIMAL(18,2)
COLUMN_FORMAT ENCODING FIXED -- 金額字段列存
) ENGINE=InnoDB SECONDARY_ENGINE=RAPID;
- 索引設計雙模式
TP側索引規范 ：
- 必須為所有主鍵/外鍵創建B-tree索引。
- 避免超過3列的復合索引。
- 索引字段總長度建議≤64字節（防止頁分裂）。
AP側索引規范 ：
-
對枚舉型字段（如
status）創建位圖索引：CREATE BITMAP INDEX idx_order_status ON orders_columnar(status); -
對分析常用字段建立投影（Projection）：
ALTER TABLE sales ADD PROJECTION p_region_month ( SELECT region, MONTH(date), SUM(amount) GROUP BY region, MONTH(date) );
