主鍵（Primary Key）

單實例數據庫不要求表一定要有主鍵，但是對于分布式數據庫，主鍵則是必須的，以保證一行數據是全局唯一的，避免遷移過程出現問題。如果用戶沒有特殊的性能需求或業務耦合問題，則應將主鍵設計為無意義的整數值或者自增的數值。

分區鍵（Partition Key）

用戶的分區表必須按照一種維度進行數據劃分，用戶在按照分區鍵維度進行查詢時，就能做到線性性能增長，分區鍵通常有如下選擇方法：

• 按業務ID切分，如用戶ID、商品ID等，適合每個業務ID的數據較均勻且查詢簡單的場景；
• 按多個業務維度切分，用戶建立多張表存入相同數據，但是每張表按照不同業務維度切分，查詢時根據過濾條件選擇不同的表，以提升訪問性能，適合查詢復雜且單一切分方式不能滿足需求的場景；
• 按自增主鍵切分，若表分區方式為分區表，主鍵為自增，且該字段同時為分區鍵，則此時寫入為隨機分區，按照非主鍵查詢時需要讀取所有分區，適合有數據偏斜且寫多讀少的場景；
• 至少保證在分區鍵上有一個索引。

業務列

其它的列統歸為此類，僅用于存儲數據，通常要考慮：

• 列不宜過長，夠用即可，臨時加載的長列會消耗額外內存，影響查詢性能；
• 準確定義列的類型，避免查詢時使用的類型與表定義的類型不匹配，從而進行類型轉換，以致不能正確使用索引；
• 優先使用timestamp類型代替其它時間日期類型，且使用時嚴格遵守MySQL的時間日期格式。

主鍵索引

若主鍵是自增類型，則主鍵索引不會對整體性能優化有改善，若主鍵與業務相關，則可以對最頻繁使用的SQL語句的查詢條件建立主鍵索引，這樣可以提升性能。

輔助索引

其他情況下，如果不能通過將SQL語句拆解成單分區的，且不能利用主鍵進行索引優化時，需要對全部分區進行掃描，此時可以對這部分全分區掃描的語句的查詢條件建立索引，使得在每個分區上進行訪問時，仍然能取得較高的性能