問題
收到一個問題，說有個列表在測試和預發環境排序沒有問題，在線上就有問題。
然後定位是 sql 沒有加排序。加上排序後就 OK了。
這是爲什麼呢？當然是因爲測試和預發環境沒有做分庫分表啦。
測試環境裏數據庫只有一個，表也只有一份，所以列表的數據來自同一個庫，同一個表。排序是按數據庫的默認排序。
線上是有分庫，不同數據庫裏的數據，取出來後再做聚合，沒有排序的話是會有亂序的。
分庫分表後的使用姿勢
1） 排序
數據來自不同的表或庫，首要的影響就是排序。按實現方案的不同，有不同的排序方式 ， mycat ， shardingsphere 會自動排序。
沒有使用中間件的話，就需要自己實現排序。
2）數據查詢聚合
查詢後的數據在聚合時，需要發生些變化。因此需要儘量減少多表關聯的查詢。多表的關聯查詢比較考驗分表的能力。分庫分表沒分好的話，那麼在數據聚合時的性能壓力會比較大。
我們團隊的開發規範是禁止多表查詢，包括子查詢和 join 查詢。
3）事務
數據分庫後，事務是重點。
分佈式事務，結合本地事務使用。
當然中間件能給你很多便利。
4）ID 主鍵
分庫，分表後ID 最好用來做主鍵，不要用來排序。排序可以用時間或其他有標識的字段。
ID 生成則可以使用ID 生成算法或 ID 生成服務。例如：Snowflake 是 Twitter 開源的分佈式 ID 生成算法，結果是一個 long 型的 ID。
5）讀寫分離
準確來說這不是分庫，而是優化。讀寫分離，提高效率。