mysql5.5 uuid作主鍵與int作主鍵的性能實測

偶然的機會，得知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！！