在mysql中設計表的時候，mysql官方並不推薦使用uuid或者不連續不重複的雪花id，而是推薦使用連續自增的主鍵id。
官方推薦的是auto_increment。主要原因是uuid在資料量較大的情況下，效率直線下滑。
使用自增id的內部結構
自增的主鍵的值是順序的，所以innodb把每一條記錄都儲存在一條記錄的後面。當達到頁面的最大填充因子的時候（innodb是15/16）
下一條記錄會寫入新的頁中，一旦資料按照這種順序的方式載入，主鍵頁就會近乎於順序的記錄填滿，提公升了頁面的最大填充率，不會有頁的浪費
新插入的行一定會在原有的最大資料行的下一行，mysql定位和定址很快，不會為計算新行的位置而做出額外的消耗
減少了頁**和碎片的產生缺點
使用uuid的索引內部結構
因為uuid毫無規律可言，新值和舊值大小無法確定，所以需要innodb要為新行尋找新的合適的位置從而來分配新的空間。會導致以下幾個問題：
把隨機值（uuid和雪花id）載入到聚簇索引（innodb預設的索引型別）以後，有時候會需要做一次optimeize table來重建表並優化頁的填充，這將又需要一定的時間消耗。總結：
使用innodb應該盡可能的按主鍵的自增順序插入，並且盡可能使用單調的增加的聚簇鍵的值來插入新行
mysql為什麼不推薦使用uuid作為主鍵
前言 在mysql中設計表的時候,mysql官方推薦不要使用uuid或者不連續不重複的雪花id long形且唯一 而是推薦連續自增的主鍵id,官方的推薦是auto increment,那麼為什麼不建議採用uuid,使用uuid究竟有什麼壞處？本篇部落格我們就來分析這個問題,一下內部的原因。1.1 要...
開源不應作為推薦的理由
明天去學校啦，近兩個月的暑假結束了，來總結總結這個暑假的經歷。早在放假前，我就計畫好了，這個暑假一定要熟悉一下 linux 的使用。在這個期間，我也看到很多開源人士和 windows 的鐵桿粉絲們在論壇等地方吵架。有個支援開源的朋友說 當你聽到開源軟體時是什麼感覺？給我的，是感覺親切，沒有濃重的商業...
MySQL 為什麼推薦自增 id 作為主鍵
在計算機裡，無論是記憶體還是磁碟，作業系統都是按頁的大小進行讀取的 頁大小通常為 4 kb 磁碟每次讀取都會預讀，會提前將連續的資料讀入記憶體中，這樣就避免了多次 io，這就是計算機中有名的區域性性原理，即我用到一塊資料，很大可能這塊資料附近的資料也會被用到，乾脆一起載入，省得多次 io 拖慢速度，...