用 InnoDB 時關於 PRIMARY KEY 的建議

Percona 的「 InnoDB scalability issues due to tables without primary keys」這篇文章在討論 InnoDB 在沒有 PRIMARY KEY 時的效能問題。

在討論效能問題前，應該先讀過 MySQL 官方文件裡提到 InnoDB index 架構的文章，其中就有提到 PRIMARY KEY 以及其他的 INDEX KEY 的底層架構：「 InnoDB Table and Index Structures」。

InnoDB 是 clustered index 架構 (關於 clustered index 的完整說明，可以參考維基百科的「 Database index」條目)，也就是說，資料本身 (row data) 存放時會按照某個順序存放，這邊的順序是按照這樣的方式定義的：

• 如果你有指定 PRIMARY KEY，那麼就會直接用 PRIMARY KEY 當作 clustered index。
• 如果沒有指定 PRIMARY KEY，但有 UNIQUE INDEX，而且所有欄位都是 NOT NULL，那麼就用這組 UNIQUE INDEX (NOT NULL) 當作 clustered index。
• 如果都沒有指定 PRIMARY KEY，那麼就會產生一個隱藏的欄位，是一個 6 bytes 的 auto increment 的數字，用這個欄位當 clustered index。也因為如此，在這種情況下，資料會依照建立的順序存放。

另外，InnoDB 的 secondary index 會指到 PRIMARY KEY (B+Tree 的 value 部分是放 PRIMARY KEY)。

所以，一般在規劃資料庫時建議的作法是：

• 所有的表格都要有 PRIMARY KEY。
• PRIMARY KEY 必須是 INT UNSIGNED (4 bytes)，只有在需要 BIGINT UNSIGNED (8 bytes)的時候才用 BIGINT UNSIGNED。

對於有大量 secondary index 的表格更應該這樣做 (因為可以省下大量空間)。而對於現代的 ORM 來說，也都幾乎要求要有 PRIMARY KEY，甚至有些 ORM 要求 PRIMARY KEY 必須是 single column。

如果你都能了解後，再去看 Percona 討論沒有 PRIMARY KEY 的情況時，才能了解他們想要討論什麼事情… 裡面還包含了 InnoDB 格式的差異。

Related Posts:

• 用 Percona XtraBackup 備份時用 compact 模式節省空間…
• Percona 對 InnoDB 效能的建議…
• 把 MySQL MyISAM 換到 Galera Cluster 的 InnoDB 上…
• MySQL 對 VARCHAR 的 Index 空間佔用的問題…
• Percona 的「Advanced MySQL Query Tuning」…