不一定
自增主鍵可以加快行的插入速度，對於表的空間利用上有優勢，碎片化不明顯。
但是對一些內容，如根據uid的查詢非常頻繁的，而且比較集中的，那如果不用自增主鍵，而是使用uid+id作為複合主鍵，那查詢效率會上去，但插入和碎片化就會增加。但如果資料庫的儲存類型是ssd，那這個問題就不存在了。
所以，大部分情況來看，表有自增主鍵是正確的。
不一定
單表結構下，是的。
多表情況下，不一定，需要一定的策略，如設定不同的後綴，相同的間隔等。
不建議這樣做。
如：表可以有自增主鍵，表內是具有唯一性的。根據id查詢和更新的時候，可以簡化操作。但一般來說，和業務上存在關係，並且需要唯一性的時候，應該由業務自主去維護，如使用格式或演算法，hash生成等方式。
維護自增鍵區間段，伺服器每次取其中的一段，樂觀鎖定更新。這個需要額外的表格或策略來維護這個欄位。
基於演算法A，固定時間前綴，如：yyyyMMddHHmmss+表數mod值+隨機數，透過位數的增加，來降低衝突的可能性。表格字段存在唯一性約束（但有時這個約束並不可靠）插入時若拋出重複字段值異常，則重新生成插入。
基於演算法B，固定時間前綴，如：yyyyMMddHHmmss+固定位數碰撞自增值N+隨機數。不需要透過位數的增加來降低衝突的可能性。當插入拋出重複字段值異常時，N++，重新插入，直到不再衝突為止。此後固定使用N作為中綴，且N快取於伺服器，重啟後繼續使用此中綴。若出現重複異常，再次N++執行相同操作即可。 N的mod值這些就不用故意提起囉。
基於中綴管理，即上報中綴到中心伺服器，可以理解有地方快取了伺服器的id關係，動態分配中綴。
其他方法，還有很多，也沒用過，不贅述了。
演算法B，簡單，通訊少，而且碰撞次數有限。演算法A，存在無限次數的碰撞，儘管百分比非常非常低。但是在高並發的情況下，初始化的時候，演算法B會比演算法A來得更狂風暴雨一些。
區間段和中綴管理，都引入了中心節點的概念，依賴性比較強，但相對可靠，業界更為通用的實現方式。
以上是資料庫是否自增主鍵？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
