1樓：孤狐無悔
回答如下：
1、自增ID主要是作為主鍵。
2、自增避免重複。
3、不一定有優勢，但主要優勢是在滿足主鍵條件的情況下減少開發勞動。
不只是MySQL，其他的關係型資料庫，例如MS SQL，Oracle，都有同樣的功能。
自增ID列不一定要加，加了不一定有優勢，有時反而有劣勢。
但是許多情況加上（並設定為主鍵）比較好，具體說明如下。
1、為了查詢速度，方便刪改，除了非常注重「插入（Insert）」速度的表之外，都應當使用主鍵。
2、主鍵必須唯一，不可為空，也就是說整個表中不可以有重複的主鍵，也不可以讓主鍵空著。。
3、如果表的列中沒有適合作為主鍵的，建議使用自增ID。
不適用自增ID的情況：
a. 用於log, transaction等插入操作極多，查詢和修改極少的表，可以不設主鍵，也不設自增ID，以加快插入速度。
b. 有其他適合的內容作為主鍵。例如，以身份證、手機號碼作為主鍵，公司員工表可以使用公司員工編號作為主鍵。
c. 使用其他型別的縮寫、編碼作為主鍵同時作為其他表的外來鍵，可以在開發維護時，更加容易的理解資料內容。（注意，有風險）
d. 有更嚴格的防重複要求，不使用自增ID，而是使用GUID或者Trigger來產生主鍵。
2樓：地山
所謂relational database，要有relationship才叫relational database啊。你如果乙個表什麼都裝，既不符合正規化模型，資料冗餘，查詢也緩慢。所以要把資料拆開成多個表，拆開為了保持舊有的relationship，就要用key把他們連線起來。
為了方便你操作，系統就提供乙個功能，自動給你維護乙個key，如此而已。並不是每個都有自動增加的key，你不要，系統是不會建立的。
3樓：
1 主鍵這個東西一定要有,沒有的話很不習慣,也不方便以後查詢關聯資料
2 uuid也可以的,唯一就行,沒必要一定自增吧.當然自增的可能方便一點點
3 優勢大概就是相比uuid簡單一點點,我自己喜歡uuid多一點.
4樓：沈磊
不談高逼格東西，從普通人角度來認識。一，id，如同身份證號，名字可以重複，但身份證號是唯一的；二，自動增長，從程式設計角度來說，更簡便，不用花心思去管這塊了；三，優勢呢，兩個表關聯，可能用到id，查詢記錄，可能用到id，就把它當警察叔叔通過身份證號碼來找你一樣性質——沒身份證號碼，天不會塌，但會亂。。。
5樓：
InnoDB 使用兩種索引來組織資料，Clustered Index 和 Second Index
Clustered Index 與主鍵有千絲萬縷的關係，可以簡單認為是相等關係，資料儲存會按照主鍵來進行排序。
如果在建表的時候不提供主鍵，InnoDB 會自動生成乙個主鍵，這個主鍵是字元式的，所以當有新資料進來的時候，原先的排序會被打亂，中間的開銷會很高。簡單說就是那棵樹的左旋右旋，很麻煩。
使用自增 ID 充當主鍵，就可以解決這個問題了，相應的 Second Index 的查詢效率也會變高。
二建證書聘用的時候一般需要什麼資料？
一線天 初始註冊需提交材料如下 申報材料應當用A4紙影印 1 建造師初始註冊申請表 一式三份 2 建造師初始註冊審批意見表 一式乙份 3 聘用執業單位的企業資質證書影印件 若聘用執業單位尚未取得企業資質證書的，則提供 企業法人營業執照 影印件。4 本人的建造師執業資格證書 學歷證書和身份證明影印件 ...
資料分析的一般流程有哪些？
深海 通用型的資料分析可以參考 CRISP DM cross industry standard process for data mining 即為 跨行業資料探勘過程標準 上圖的外圈象徵資料探勘自身的迴圈本質 在乙個解決方案發布之後乙個資料探勘的過程才可以繼續。在這個過程中得到的知識可以觸發新的...
建築師在做建築外立面設計的時候一般的思路是怎麼樣的？
曾經做過兩年的建築外立面設計狗，說實話，大多數情況都是設計出來乙個作品，才開始由作品編自己的理念 正如一位好友經常說的一句話，設計是別人的，藝術是自己的 雪無 1.按照符合主流建築審美的角度來說，優美的建築立面設計應該是內部空間關係和功能組織有邏輯地表現。外立面不應該由建築師人為刻意地去雕琢和設計，...