Mongo 的 ObjectID 會在 InnoDB 的聚集索引中執行良好嗎？

Mongo 的 ObjectID 是這樣定義的：

ObjectId 是一個 12 字節的 BSON 類型，使用以下方法構造：

一個 4 字節的值，表示自 Unix 紀元以來的秒數，

一個 3 字節的機器標識符，

一個 2 字節的程序 ID，

和一個 3 字節的計數器，從一個隨機值開始。

假設 PRIMARY 鍵是 BINARY(12)，這和自動遞增的 INT 一樣有效嗎？對於 InnoDB 的聚集索引，它算作順序嗎？時間戳中的間隙會是一個問題嗎？

我相信它不會那麼好用，這就是原因。

1. 它大於 int（4 字節）或 bigint（8 字節）。請記住，每個其他索引都引用主鍵，因此它會使其他索引膨脹。這可能不是問題，但需要注意。
2. 雖然時間戳是連續的，但機器 ID、程序 ID 和隨機值並不總是如此，因此在同一秒內發生的任何事情都不總是按升序排列。

所以總而言之，我不相信 Mongo ObjectID 會像一個較小的升序鍵那樣執行。

也就是說，您仍然可以將其用作主鍵。它不需要升序，它只是意味著您可能在插入時有索引葉拆分，如果它們足夠接近末尾，就不會過度影響性能。而且您始終可以重建表以壓縮索引。

所以，更多關於葉子分裂的資訊。預設情況下，innodb 喜歡15/16 填充，留出 1/16 以供將來更改。當數據按順序插入時，索引最終總是填充到 15/16。

當數據被隨機/亂序插入時，innodb 將 1/2 到 15/16 之間的頁面保持滿，這取決於它認為索引頁面的最終填充率。當索引載入到記憶體中時，這顯然會浪費磁碟空間和記憶體。

引用自：https://dba.stackexchange.com/questions/42768