需求背景
業(yè)務表tb_image部分數據如下所示逛拱，其中id唯一，image_no不唯一公浪。image_no表示每個文件的編號劳曹，每個文件在業(yè)務系統(tǒng)中會生成若干個文件，每個文件的唯一ID就是字段id：
業(yè)務表tb_image的一些情況如下：
- 根據image_no查詢和根據id查詢蔬螟；
- 存量數據2kw此迅；
- 日增長4w左右；
- 日查詢量20w左右旧巾；
- 非ToC系統(tǒng)耸序，所以并發(fā)的天花板可見；
方案選擇
根據上面對業(yè)務的分析鲁猩，分庫分表完全沒有必要坎怪。單庫分表的話，由于要根據image_no和id查詢廓握，所以搅窿，一種方案是冗余分表（即一份數據以image_no為分片鍵保存，另一份數據以id為分片鍵保存）隙券；另一種方案是只以image_no為分片鍵男应，而基于id的查詢需求，業(yè)務層進行結果歸并或者引入第三方中間件娱仔。
考慮到單庫分表比較復雜沐飘，所以決定使用分區(qū)特性，而且容量評估分區(qū)表方案128個分區(qū)（每個分區(qū)數據量kw級別）完全能保證業(yè)務至少穩(wěn)定運行15年（圖中橙色部分是比較貼合自身業(yè)務實際增長情況）：
另外，由于RANGE, LIST, HASH分區(qū)都不支持VARCHAR列耐朴，所以決定采用KEY分區(qū)借卧，官方介紹它的原理是以MySQL內置hash算法然后對分區(qū)數取模。
性能測試
選定分片鍵為image_no筛峭，并且決定分區(qū)數為128后铐刘，就要灌入數據進行可行性和性能測試了。分區(qū)數選擇128的原因是：11億/1kw=110≈128蜒滩，另外程序員情節(jié)滨达，喜歡用2的N次方，你懂的俯艰。然而捡遍，這個分區(qū)數128就是一切噩夢的開始。
我嘗試先插入10w數據到128個分區(qū)中竹握，插入后画株，讓我驚訝的現(xiàn)象出現(xiàn)了：所有奇數編號分區(qū)（p1, p3, p5, ... , p2n-1）中居然沒有一條數據，同時啦辐，任何一個偶數編號分區(qū)卻有很多的數據谓传，而且還不是很均勻。如下圖所示：
說明：奇數編號分區(qū)的ibd文件大小都是112k芹关，這是創(chuàng)建分區(qū)表時初始化大小续挟，實際并沒有任何數據。我們可以通過SQL：select partition_name, partition_expression, table_rows from information_schema.partitions where table_schema = schema() and table_name='image_subpart';驗證侥衬，其部分結果如下圖所示：
難道10w條數據還不夠說明問題诗祸？平均下來每個分區(qū)可是有近800條數據！好吧轴总，來點猛的：我再插入990w條數據直颅，總計1kw數據。結果還是一樣怀樟，奇數編號分區(qū)沒有數據功偿，偶數編號都有分區(qū)。
問題思考
我們再來回想一下KEY分區(qū)的原理：通過MySQL內置hash算法對分片鍵計算hash值后再對分區(qū)數取模往堡。這個原理也可以從MySQL官網找到械荷，請戳鏈接：22.2.5 KEY Partitioning: https://dev.mysql.com/doc/refman/5.7/en/partitioning-key.html，截取原文如下：
Partitioning by key is similar to partitioning by hash, except that where hash partitioning employs a user-defined expression, the hashing function for key partitioning is supplied by the MySQL server. NDB Cluster uses MD5() for this purpose; for tables using other storage engines, the server employs its own internal hashing function which is based on the same algorithm as PASSWORD().
這個世界上不會有這么渣渣的hash算法吧虑灰？隨便寫個什么算法也不至于這么不均勻吧养葵？這時候我懷疑是否有一些什么配置引起的。但是show variables中并沒有任何與partition相關的變量瘩缆。
這個時候，一萬匹馬奔騰而過佃蚜。會不會是文檔和源碼不同步導致的庸娱？好吧着绊，看MySQL的源碼，畢竟熟尉，源碼才是最接近真相的地方归露。KEY分區(qū)相關源碼在文件sql_partition.cc中，筆者截取部分關鍵源碼斤儿，如下所示剧包，初略觀察，并沒有什么不妥往果，先計算分區(qū)字段的hash值然后對分區(qū)數取模：
/**
Calculate part_id for (SUB)PARTITION BY KEY
@param file Handler to storage engine
@param field_array Array of fields for PARTTION KEY
@param num_parts Number of KEY partitions
@param func_value[out] Returns calculated hash value
@return Calculated partition id
*/
inline
static uint32 get_part_id_key(handler *file,
Field **field_array,
uint num_parts,
longlong *func_value)
{
DBUG_ENTER("get_part_id_key");
// 計算分區(qū)字段的hash值
*func_value= file->calculate_key_hash_value(field_array);
// 對分區(qū)數取模
DBUG_RETURN((uint32) (*func_value % num_parts));
}
懷著絕望的心情疆液，請出搜索引擎搜索："KEY分區(qū)數據不均勻"，搜索結果中的CSDN論壇（https://bbs.csdn.net/topics/390857704）里有個民間高手華夏小卒回答如下：
一個同事根據password函數陕贮，分析并測出堕油，key分區(qū)，只能指定分區(qū)數目為質數肮之，才能保證每個分區(qū)都有數據掉缺。我測了下，從11個分區(qū)戈擒，到17個分區(qū)眶明。 只有11,13,17 ，這3個分區(qū)的數據是基本平均分布的筐高。
這個時候犬辰，又是一萬匹馬奔騰而過。不過F**K的同時冰单，心里也是有點小激動，因為可能找到解決辦法了（雖然還不知道MySQL內置hash算法為毛會這樣）诫欠，最后筆者再次對KEY分區(qū)測試并總結如下：
- 如果設置40涵卵，64，128等偶數個分區(qū)數（PARTITIONS 64）荒叼，會導致編號為奇數的分區(qū)（p1, p3, p5, p7, ... p2n-1）完全插不進數據；
- 如果設置63，121（PARTITIONS 63）這種奇數但非質數個分區(qū)數看疙，所有分區(qū)都會有數據施禾，但是不均勻拓巧；
- 如果設置137承耿，31這種質數個分區(qū)數（PARTITIONS 137），所有分區(qū)都會有數據捷泞，并且非常均勻；
如下圖所示，是筆者把分區(qū)數調整為127并插入100w數據后的情況劈狐，通過SQL證明每個分區(qū)的數據量幾乎一樣：
總結回顧
MySQL的KEY分區(qū)這么大的使用陷阱谒兄，居然在官方上沒有任何說明燕鸽，這讓筆者感到非常震驚麸锉。筆者還嘗試Google搜索mysql partition key uneven磷脯，也有很多結果，例如stackoverflow：https://stackoverflow.com/questions/38454354/mysql-uneven-distribution-of-data-into-partitions-when-using-key-partitioning娩脾，此外還有MySQL bug：Bug #72428 Partition by KEY() results in uneven data distribution
正在看此文并有很強烈興趣的同學赵誓，可以嘗試更深入這個問題。筆者接下來也會找個時間柿赊，根據MySQL源碼深入挖掘其hash算法的實現(xiàn)為什么對分區(qū)數如此敏感俩功。
