設計 MySQL 數據表的時候一般都有一列為自增 ID，這樣設計原因是什麼，有什麼好處？

12-30

包含三個角度

為什麼要加這一列 ID ？

這列 ID 為什麼要自增？

這樣做的優勢在哪裡？

MyISAM/InnoDB默認用B-Tree索引(可理解為"排好序的快速查找結構")。

InnoDB中，主索引文件上直接存放該行數據，稱為聚簇索引。次索引指向對主鍵的引用；

MyISAM中，主索引和次索引，都指向物理行(磁碟位置)；

注意: 對InnoDB來說

1: 主鍵索引既存儲索引值，又在葉子中存儲行的數據;

2: 如果沒有定義主鍵，則會使用非空的UNIQUE鍵做主鍵 ; 如果沒有非空的UNIQUE鍵，則系統生成一個6位元組的rowid做主鍵;

聚簇索引中，N行形成一個頁。如果碰到不規則數據插入時，會造成頻繁的頁分裂(因為索引要排好序)，插入速度比較慢。所以聚簇索引的主鍵值應盡量是連續增長的值，而不是隨機值(不要用隨機字元串或UUID)，否則會造成大量的頁分裂與頁移動。

故對於InnoDB的主鍵，盡量用整型，而且是遞增的整型。這樣在存儲/查詢上都是非常高效的。

資料庫表一般使用 B+樹索引， B+樹的葉子節點存放所有指向關鍵字的指針，節點內部關鍵字記錄和節點之間都根據關鍵字的大小排列。

當順序遞增插入的時候，只有最後一個節點會在滿掉的時候引起索引分裂，此時無需移動記錄，只需創建一個新的節點即可。而當非遞增插入的時候，會使得舊的節點分裂，還可能伴隨移動記錄，以便使得新數據能夠插入其中。

一般建議使用一列順序遞增的 ID 來作為主鍵，但不必是資料庫的autoincrement欄位，只要滿足順序增加即可，如 twitter 的 snowflake 即為順序遞增的 ID 生成器。

Update: 這裡有一篇博客，圖文並茂講的很清楚 http://hedengcheng.com/?p=525

1 主鍵這個東西一定要有,沒有的話很不習慣,也不方便以後查詢關聯數據

2 uuid也可以的,唯一就行,沒必要一定自增吧.當然自增的可能方便一點點

3 優勢大概就是相比uuid簡單一點點,我自己喜歡uuid多一點.

所謂relational database，要有relationship才叫relational database啊。你如果一個表什麼都裝，既不符合範式模型，數據冗餘，查找也緩慢。所以要把數據拆開成多個表，拆開為了保持舊有的relationship，就要用key把他們連接起來。為了方便你操作，系統就提供一個功能，自動給你維護一個key，如此而已。並不是每個都有自動增加的key，你不要，系統是不會創建的。

InnoDB 使用兩種索引來組織數據，Clustered Index 和 Second Index

Clustered Index 與主鍵有千絲萬縷的關係，可以簡單認為是相等關係，數據存儲會按照主鍵來進行排序。

如果在建表的時候不提供主鍵，InnoDB 會自動生成一個主鍵，這個主鍵是字元式的，所以當有新數據進來的時候，原先的排序會被打亂，中間的開銷會很高。簡單說就是那棵樹的左旋右旋，很麻煩。

使用自增 ID 充當主鍵，就可以解決這個問題了，相應的 Second Index 的查詢效率也會變高。

不談高逼格東西，從普通人角度來認識。一，id，如同身份證號，名字可以重複，但身份證號是唯一的；二，自動增長，從編程角度來說，更簡便，不用花心思去管這塊了；三，優勢呢，兩個表關聯，可能用到id，查找記錄，可能用到id，就把它當警察叔叔通過身份證號碼來找你一樣性質——沒身份證號碼，天不會塌，但會亂。。。

這個ID用作其它表外鍵時能提高查詢效率。對於自身表沒什麼意義。

因為你需要一個唯一的標誌來區分這個表裡面的每一行，又不想費時費事去自己弄一個