偶然的機會，得知mysql主鍵的類型采用 varchar 存UUID 的查詢性能沒有int型做主鍵好。網(wǎng)上查詢大量資料，都是停留在理論上的，因此，自己寫了代碼進行實測，以下結(jié)果僅供參考，不具備權威性。

三個表的字段，除了主鍵ID 分別采用varchar，bigint 和自動增長bigint不同外，其他三個字段都為 varchar 36位

數(shù)據(jù)庫：mysql5.5

表類型：InnoDB

數(shù)據(jù)量：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()產(chǎn)生數(shù)據(jù)，數(shù)據(jù)為有序列的純數(shù)字(22461015967875697)。(其相當于自動增長，只是固定的基數(shù)值較大而已。)

運行查詢語句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自帶的自動增長，數(shù)據(jù)為純數(shù)字(1，2，3，4，5……)。

查詢語句1消耗時間平均為：1.07秒；

查詢語句2消耗時間平均為：1.31秒;

查詢語句3消耗時間平均為：0秒；(多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000)

總結(jié)：由此可見，mysql InnoDB 主鍵采用自動增長性能較高。

筆者自語：平時的項目開發(fā)，sql語句的條件里有ID的，占多數(shù)，沒有的占少數(shù)。雖然以上的測試表明只要條件語句里有主鍵ID，主鍵類型不一樣，查詢時間完全一樣。但是，你不能保證你的項目中所有sql語句的條件里都有ID，因此…………主鍵的類型該采用哪種，相信各位看官已經(jīng)明白。

———————————————————華麗的分割線———————————————————-

數(shù)據(jù)庫：mysql5.5

表類型：MyISAM

數(shù)據(jù)量：100W條

為了少寫一些字，節(jié)省時間，此測試所使用的表和sql語句同上，此處只記錄消耗時間。

第一種情況：

主鍵采用uuid 32位。

語句1消耗時間平均為：0秒；

語句2消耗時間平均為：0.53秒；

語句3消耗時間平均為：0秒；(多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000)

第二種情況：

主鍵采用bigint，使用uuid_short()產(chǎn)生數(shù)據(jù)，數(shù)據(jù)為有序列的純數(shù)字(22461015967875697)。(其相當于自動增長，只是固定的基數(shù)值較大而已。)

語句1消耗時間平均為：0秒；

語句2消耗時間平均為：0.51秒；

語句3消耗時間平均為：0秒；(多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000)

第三種情況：

主鍵采用mysql自帶的自動增長，數(shù)據(jù)為純數(shù)字(1，2，3，4，5……)。

語句1消耗時間平均為：0秒；

語句2消耗時間平均為：0.48秒；

語句3消耗時間平均為：0秒；(多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000)

總結(jié)：由此可見，mysql MyISAM 主鍵采用自動增長性能比其他有微弱的優(yōu)勢。測試數(shù)據(jù)為100w，如果是1000W 1億，我想這個優(yōu)勢會拉大，如果你還有外鍵關聯(lián)查詢，這個優(yōu)勢就更明顯了。當然，如果你設計的系統(tǒng)，數(shù)據(jù)量還沒有超過100W，你用啥主鍵類型都無所謂。我測試電腦是筆記本，如果是專業(yè)的服務器，估計100W條，mysql MyISAM 的這些測試，根本都測不出來時間差。

大總結(jié)：本來是要測mysql主鍵類型不同，查詢效率的差別的，怎么寫到最后，感覺像是在測mysql InnoDB和MyISAM的優(yōu)劣了，無限糾結(jié)中……，有時間測下oracle！！

來源：http://j2ees.iteye.com/blog/1554423

總結(jié)

以上是生活随笔為你收集整理的mysql int做主键_mysql5.5 uuid做主键与int做主键的性能实测的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。