有間隙的主鍵 ID 的性能（但按順序）

我知道擁有非順序 ID 對索引性能不利。但假設我所有的 ID 都是按正確的順序創建的，但有很大的差距：即：

154300000
283700000
351300000
464200000

…性能會比無間隙的 auto_increment ID 更差嗎？

我將使用 MySQL，或者可能是 PostgreSQL。ID之間的差距不會是均勻的。它們將是 BIGINT，在數字的開頭（左側）帶有 unix 時間戳，其餘數字大多是隨機的，正如我在此處提出的另一個問題中所討論的：

https://stackoverflow.com/questions/6338956/mysql-primary-keys-uuid-guid-vs-bigint-timestamprandom/6339581

作為聚集鍵的非順序列可能是一個問題，特別是如果它們像大多數 UUID 生成器輸出一樣非常隨機，但問題在於隨機性而不是間隙。在現有值的中間插入一個值有可能導致頁面拆分，但插入一個大於最大值的鍵並不比插入下一個值更有可能。

順便說一句，一些 UUID 生成器輸出相對順序的值。這些適用於當您將這樣的列作為聚集鍵或其他聚集索引中的重要成員時。

如果您還沒有閱讀過有關創建和維護平衡樹結構的任何內容，並且您有一些空閒時間，我建議您找一章關於這件事的半體面的章節（可能是針對電腦科學一年級學生的水平）——它’將幫助您了解工作數據庫對管理您的結構所做的工作，以便您更好地了解什麼會有所幫助，什麼會阻礙（以及任何一種方式都不會產生什麼影響）。

就 PostgreSQL 而言，您的假設

具有非順序 ID 對索引性能不利

一般是不正確的。有一些特殊的案例，其中序號有所幫助，但對索引性能沒有幫助。在正常操作中，它沒有任何區別。

對值的操作UUID比 on 慢一些，因為它們是 16 字節寬（而不是 4 / 8 字節）int。bigint

通常，連續 ID 號有間隔是規則，而不是例外。

對於您的特殊情況，如果您有少量實例並控制它們，您可以留出單獨的 a 範圍，bigint甚至只是int:具有預設START值的序列，例如。由於您沒有大量插入，因此應該有很多數字。

對於更多情況或如果您無法控制，我強烈建議您使用UUID而不是任何本土解決方案。這是一種成熟的、經過充分測試的技術，並且表現良好。

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