假設自動遞增主鍵是按照時間順序設計的錯誤設計？

Question

或者更確切地說，積極因素是否大於消極因素？

目標是獲得N個最近的記錄。

優點：

1. 不必指數created_at列
2. 你的ORDER BY將使用聚集索引

缺點：

1. 你依靠主鍵的時間有序性來保證開發週期的生命

想法？

Answer 1

由於數據庫事務，多個會話可能會在不同的時間提交，您會發現它並不總是按時間排序。

另一個騙子是沒有創建於created_on一個指標，你忘了提：

• 無法搜索或特定的日期/時間或範圍過濾器。

我覺得這個問題只能根據需求來回答。

Answer 2

雖然這是常見的做法，但有很多情況下主鍵變得無序。我經常遇到這個問題。我個人發現最好設置創建時設置的created_at列。

Answer 3

除非將所有插入操作序列化，否則可能無法保證自動遞增鍵的順序是按時間順序排列的。

如果您使用代理鍵來確定序列並從中驅動業務邏輯，那麼您也首先破壞了代理鍵的主要優勢。替代品應該沒有商業意義，例如，您可以在數據庫維護和模式更改期間輕鬆更新/重新分配這些值。