以預設的innodb儲存引擎為例：
做為主鍵時，uuid和自增相比較，自增更適合。
原因：1 uuid是無序的， 插入資料時，頁的位置會發生變化，頁**，速度慢。
2 uuid佔的空間大，並且innodb中，別的索引還都要包含主鍵的值，那麼每個索引的空間也都會增大，佔的空間大，需要讀資料時一般會認為需要的io次數多。
自增也是有缺點的
可見my blog
下面來乙個模擬乙個場景證明第二個觀點：
思路：1 建表有三列(主鍵，姓名，性別)， 乙個表是uuid為主鍵，乙個表是自增為主鍵
插入同樣的記錄數
2 對「性別」列加索引，對比索引大小。索引大的佔的空間多
mysql> create table song_auto_inc(id int primary key auto_increment,name varchar(10),*** char(1));
query ok, 0 rows affected (0.01 sec)
mysql> create table song_uuid(id varchar(36) primary key ,name varchar(10),*** char(1));
query ok, 0 rows affected (0.00 sec)
cat insert_auto_inc.sh --插入自增表
#!/bin/bash
while true; do
mysql -h10.13.12.197 -p3306 -uroot -ptest -e "insert into test.song_auto_inc (name,***) select 'name1','1' ;"
done
cat insert_uuid.sh --插入uuid
#!/bin/bash
while true; do
mysql -h10.13.12.197 -p3306 -uroot -ptest -e "insert into test.song_uuid select uuid(),'name1','1' ;"
done
插入資料：
sh insert_auto_inc.sh
sh insert_uuid.sh
mysql> select count(*) from song_auto_inc;
| count(*) |
| 197806 | --記錄數一樣
1 row in set (0.03 sec)
mysql> select count(*) from song_uuid;
| count(*) |
| 197806 | --記錄數一樣
1 row in set (0.03 sec)
--去掉兩個表中的碎片
mysql> optimize table song_auto_inc;
| table | op | msg_type | msg_text |
| test.song_auto_inc | optimize | note | table does not support optimize, doing recreate + analyze instead |
| test.song_auto_inc | optimize | status | ok |
2 rows in set (4.32 sec)
mysql> optimize table song_uuid;
| table | op | msg_type | msg_text |
| test.song_uuid | optimize | note | table does not support optimize, doing recreate + analyze instead |
| test.song_uuid | optimize | status | ok |
2 rows in set (10.71 sec)
--檢視資料檔案大小：
-rw-rw---- 1 mysql mysql 8.5k jul 23 23:10 song_auto_inc.frm
-rw-rw---- 1 mysql mysql 7.0m jul 23 23:10 song_auto_inc.ibd
-rw-rw---- 1 mysql mysql 8.5k jul 23 23:13 song_uuid.frm
-rw-rw---- 1 mysql mysql 14m jul 23 23:13 song_uuid.ibd
加索引mysql> create index idx_song_uuid_*** on song_uuid(***);
query ok, 0 rows affected (5.51 sec)
records: 0 duplicates: 0 warnings: 0
mysql> create index idx_song_auto_inc_*** on song_auto_inc(***);
query ok, 0 rows affected (0.91 sec)
records: 0 duplicates: 0 warnings: 0
再次檢視資料檔案大小：
-rw-rw---- 1 mysql mysql 8.5k jul 23 23:19 song_auto_inc.frm
-rw-rw---- 1 mysql mysql 13m jul 23 23:19 song_auto_inc.ibd
-rw-rw---- 1 mysql mysql 8.5k jul 23 23:19 song_uuid.frm
-rw-rw---- 1 mysql mysql 24m jul 23 23:19 song_uuid.ibd
自增主鍵的表大小是 7m
uuid主鍵的表大小是14m
自增主鍵二級索引大小是 13-7=6m
uuid主鍵二級索引大小是 24-14=10m
可以證明第二個觀點。
第乙個觀點留給讀者自己驗證
上面的測試是在ucloud(ucloud – 專業雲計算服務商)的mysql5.6的普通udb上完成的，如果對比插入時的效能不滿意，可以使用ssd的udb，ssd的效能非常高。在網上看到這個文章，裡面用ucloud ssd mysql和別的雲服務商進行對比，可以參考下。
qq 273002188 歡迎一起學習
qq 群 236941212
oracle,mysql,pg 相互交流
MySQL 為什麼推薦自增 id 作為主鍵
在計算機裡，無論是記憶體還是磁碟，作業系統都是按頁的大小進行讀取的 頁大小通常為 4 kb 磁碟每次讀取都會預讀，會提前將連續的資料讀入記憶體中，這樣就避免了多次 io，這就是計算機中有名的區域性性原理，即我用到一塊資料，很大可能這塊資料附近的資料也會被用到，乾脆一起載入，省得多次 io 拖慢速度，...
mysql為什麼不推薦使用uuid作為主鍵
前言 在mysql中設計表的時候,mysql官方推薦不要使用uuid或者不連續不重複的雪花id long形且唯一 而是推薦連續自增的主鍵id,官方的推薦是auto increment,那麼為什麼不建議採用uuid,使用uuid究竟有什麼壞處？本篇部落格我們就來分析這個問題,一下內部的原因。1.1 要...
為啥不推薦uuid作為Mysql的主鍵呢
在mysql中設計表的時候，mysql官方並不推薦使用uuid或者不連續不重複的雪花id，而是推薦使用連續自增的主鍵id。官方推薦的是auto increment。主要原因是uuid在資料量較大的情況下，效率直線下滑。使用自增id的內部結構 自增的主鍵的值是順序的，所以innodb把每一條記錄都儲存...