偶然的機會，得知mysql主鍵的類型采用 varchar 存UUID 的查詢性能沒有int型做主鍵好。網上查詢大量資料，都是停留在理論上的，因此，自己寫了代碼進行實測，以下結果僅供參考，不具備權威性。
三個表的字段，除了主鍵ID 分別采用varchar，bigint 和自動增長bigint不同外，其他三個字段都為 varchar 36位
數據庫：mysql5.5
表類型：InnoDB
數據量：100W條
第一種情況：
主鍵采用uuid 32位。
運行查詢語句1：SELECT COUNT(id) FROM test_varchar;
運行查詢語句2：SELECT * FROM test_varchar WHERE vname='00004629-b052-11e1-96aa-002655b28d7b';
運行查詢語句3：SELECT * FROM test_varchar WHERE id='00004599b05211e196aa002655b28d7b';
語句1消耗時間平均為：2.7秒；
語句2消耗時間平均為：3秒；
語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）
第二種情況：
主鍵采用bigint，使用uuid_short()產生數據，數據為有序列的純數字（22461015967875697）。（其相當于自動增長，只是固定的基數值較大而已。）
運行查詢語句1：SELECT COUNT(id) FROM test_long;
運行查詢語句2：SELECT * FROM test_long WHERE vname='d7f28a24-b053-11e1-96aa-002655b28d7b';
運行查詢語句3：SELECT * FROM test_long WHERE id='22461015967875702';
語句1消耗時間平均為：1.2秒；
語句2消耗時間平均為：1.40秒；
語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）
第三種情況：
運行查詢語句1：SELECT COUNT(id) FROM test_int;
運行查詢語句2：SELECT * FROM test_int WHERE vname='c80f8427-b059-11e1-96aa-002655b28d7b';
運行查詢語句3：SELECT * FROM test_int WHERE id=900000;
主鍵采用mysql自帶的自動增長，數據為純數字（1，2，3，4，5……）。
查詢語句1消耗時間平均為：1.07秒；
查詢語句2消耗時間平均為：1.31秒;
查詢語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）
總結：由此可見，mysql InnoDB 主鍵采用自動增長性能較高。
筆者自語：平時的項目開發，sql語句的條件里有ID的，占多數，沒有的占少數。雖然以上的測試表明只要條件語句里有主鍵ID，主鍵類型不一樣，查詢時間完全一樣。但是，你不能保證你的項目中所有sql語句的條件里都有ID，因此…………主鍵的類型該采用哪種，相信各位看官已經明白。
---------------------------------------------------------華麗的分割線----------------------------------------------------------
數據庫：mysql5.5
表類型：MyISAM
數據量：100W條
為了少寫一些字，節省時間，此測試所使用的表和sql語句同上，此處只記錄消耗時間。
第一種情況：
主鍵采用uuid 32位。
語句1消耗時間平均為：0秒；
語句2消耗時間平均為：0.53秒；
語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）
第二種情況：
主鍵采用bigint，使用uuid_short()產生數據，數據為有序列的純數字（22461015967875697）。（其相當于自動增長，只是固定的基數值較大而已。）
語句1消耗時間平均為：0秒；
語句2消耗時間平均為：0.51秒；
語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）
第三種情況：
主鍵采用mysql自帶的自動增長，數據為純數字（1，2，3，4，5……）。
語句1消耗時間平均為：0秒；
語句2消耗時間平均為：0.48秒；
語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）
總結：由此可見，mysql MyISAM 主鍵采用自動增長性能比其他有微弱的優勢。測試數據為100w，如果是1000W 1億，我想這個優勢會拉大，如果你還有外鍵關聯查詢，這個優勢就更明顯了。當然，如果你設計的系統，數據量還沒有超過100W，你用啥主鍵類型都無所謂。我測試電腦是筆記本，如果是專業的服務器，估計100W條，mysql MyISAM 的這些測試，根本都測不出來時間差。
大總結：本來是要測mysql主鍵類型不同，查詢效率的差別的，怎么寫到最后，感覺像是在測mysql InnoDB和MyISAM的優劣了，無限糾結中……，有時間測下oracle！！
文章列表
留言列表
