3
我正在與一名合同開發人員合作開發人員，他正在開始創建表（MySQL）而不定義主鍵。相反，他使用AUTO_INCREMENT定義了一個具有UNIQUE約束的列。我從來沒有見過這樣做，所以我想了解這樣定義表的含義。 如果需要，一個缺點是無法創建外鍵。以這種方式創建表格有什麼其他影響，無論好壞。也許我在這裏錯過了一個概念......MySQL將列定義爲UNIQUE並使用AUTO_INCREMENT而不是主鍵
A
回答
6
定義MySQL沒有顯式主鍵是一個非常非常糟糕的主意。
如果缺少PK，MySQL將創建一個隱含的（但非常真實的）整數自動增量主鍵。
此PK將包含在InnoDB的每個輔助鍵中，並將決定您在MyISAM中的主要排序順序。
後果
你剛纔放緩的每一個性能選擇，插入和更新。
沒有目的，所以永遠。
InnoDB的：去表數據
在InnoDB的一個額外的查找需要進行必需的，因爲所有二級指標指的是PK，而不是行自己額外的查找。
的MyISAM：浪費空間
在MyISAM的處罰是不是很大，但你還是沿着不習慣於一個4字節的未使用的字段拖動。
的InnoDB +的MyISAM：無用代自動增量場
的因爲隱式自動增量PK被創建，你還需要一個額外的自動遞增鍵來執行聯接;爲了防止重複的自動增量字段，您現在沒有1個，但每個插入2個表鎖。
InnoDB的：與加入上述查找probem雙打
如果聯接使用領域，這不是PK之時，InnoDB需要做一個額外的查找每聯接去其他的記錄表。
InnoDB的：最糟糕的是你失去了覆蓋索引的利益
你在InnoDB的最佳優化，覆蓋索引的殘疾人之一。
如果MySQL只能使用索引中的數據解析查詢，它將永遠不會讀取表，這會導致顯着的速度增益。現在，InnoDB中每個索引的50％都是未使用的空間，因此您不會使用該優化的機會。
請用線索棒擊敗這個承包商！
鏈接：
http://www.xaprb.com/blog/2006/07/04/how-to-exploit-mysql-index-optimizations/（低速鏈路，但推薦閱讀）。
O'Reilly on InnoDB's covering indexes http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB
BTW，如果你的承包商說，但這並沒有多大意義，因爲他使用的MyISAM，再次擊敗他，你應該總是使用InnoDB，除非你有一個很好的理由不是太。
InnoDB在生產上更加安全，MyISAM有它的用途，但也很容易被破壞。
+0
+1的唯一約束，看起來我的回答很天真！ – 2011-05-30 23:34:36
0
這不會阻止外鍵，但會影響使用該字段的查詢的性能。每當你必須查詢一個表並指定一些標準來根據列的值過濾記錄（例如WHERE子句）時，應該使用索引。
-1
主鍵只是一個與NOT NULL約束相結合的唯一索引，如果您在沒有PK的情況下滿足這些要求，那麼在性能方面沒有任何傷害，當然它仍然沒有多大意義，因爲它會混亂。
在這種情況下，您仍然可以創建外鍵。 Mysql甚至不需要對父列 – a1ex07 2011-05-30 19:44:47