爲什麼指定自動增量ID的長度

Question

我一直在使用SQL約2年，現在一直都在我的腦海。

最佳實踐說柱的長度分配給你是什麼 期待

的SQL想要一個特定的行專門作爲主鍵，但它也是最佳實踐的A_I場.. 。但分配的長度是多少？如果留空，則默認爲，它代表999,999,999

這似乎不錯，但是最佳實踐也說明從數據庫中從來沒有真正明確的東西;只是追加一個0或1來表示刪除了，這是存檔/恢復的目的。也可用於用戶想要清除..什麼審計

拿這個例子：

我有一個網站是多年來一直遵循的最佳做法，不從數據庫中刪除任何東西;我的數據庫/網站流量非常繁重，每天都有大量獨特的用戶/訪問者。

現在，如果我保留SQL默認長度爲11，如果我的表達到最大長度，然後另一個用戶決定註冊，會發生什麼？它會拋出一個錯誤，而不會繼續，這將導致新用戶的宕機時間很少，原因是數據庫管理員將不得不登錄到SQL並更改長度。哪個不是很大的努力，但它是努力可在早期發展過程中應避免..

---

我做什麼，創建表時是給出這在我的腦海裏，東西是告訴我的長度「，這不是良好的做法「，但它避免了上述例子的極小可能性。

當與沒有指定長度的text字段進行比較時，爲什麼不能在A_I字段方面相同。

不要誤解我的意思，我完全理解可用的數據類型。

---

我已經通過google和so進行了大量的研究，但結果指出了有關改變表格以增加當前長度的問題。這不是我要求的。

---

總評：

所以，總體來說，我試圖問; A_I領域的理想長度是多少？儘量減少拋出錯誤的細微風險，如果它最大限度地縮短了錯誤長度，還要記住最佳實踐。

Answer 1

原因很簡單，
作爲主鍵，該ID應該很適合您的期望。
如果指定varchar，則缺點是索引上的大小較大，可能會降低讀取和寫入性能。

int（11）..不會存儲高達99,999,999,999。
它只能存儲高達2,147,483,647。

如果你將它設置爲無符號，
那麼它可以允許的記錄4,294,967,295（4十億！）

Facebook的剛剛超過十億用戶的好評！
所以，我逼債看到任何人都可以擁有4時更大的用戶羣很快...

的最佳實踐夫婦已在這篇文章中已經解釋得非常好：

http://net.tutsplus.com/tutorials/other/top-20-mysql-best-practices/

1. 較小的列更快
2. 整數是固定長度，但varchar不是固定長度
3. 索引和用法連接的相同列類型

Answer 2

分析您的應用程序或系統。估計每天有多少用戶註冊？每年？一旦你知道這一點，然後決定你想成爲多麼「安全」 - 就你希望系統運行多少年而言，無需修改它。假設100年已經足夠了......所以，將年度用戶註冊的預期數量乘以100，並確保PK足夠大，可以同時達到許多值。