身份欄重播：什麼時候需要？
在大學的最後一堂課中（我是學生），講師要求我們開發一個數據庫（如果重要，可以使用 MySQL 伺服器）和將數據庫用作數據源的微型客戶端應用程序。
要求之一是標識列（即每個表中的 PK）必須是連續的，因為這是一種很好的做法（根據講師的話）。即當刪除表行時，它的 PK 必須在後續插入中重複使用。我在 RDBMS、PK 和身份列方面具有平均知識。據我了解，該標識列只是讓數據庫在插入行時自動生成 PK 的一種方式，僅此而已。並且標識列值不應以任何方式與行屬性相關（只要它不是自然鍵）。
這個要求（嚴格的順序標識列）對我來說很可疑。我試圖問講師，如果身份不是順序的（由於刪除導致的間隙），有什麼問題，但得到了非常抽象的答案，例如“這對使用者來說很方便，對維護數據庫的數據庫管理員很有用”。沒有具體的例子。“方便使用者”的說法聽起來很愚蠢，因為它在業務領域沒有任何意義。
因此，我很好奇這些原因是否真實？我只能想到一種需要重新設置標識列的情況——當標識空間耗盡時。但是，當標識列類型選擇不正確時，這是更多的設計問題，比如簡單
int而不是bigint表uniqueidentifier包含十億行時。假設一個標識列是一個聚集索引：標識列中的間隙會影響索引性能嗎？也許在我不知道的每次刪除後自動標識列重新播種的其他現實原因？提前致謝！
即當刪除表行時，它的 PK 必須在後續插入中重複使用。
你的講師來自哪個宇宙？？
這是非常低效的。如果您嘗試這樣做，您的績效前景將減少 10 倍。
如果出於審計原因需要無縫數字，請明確建構它們，而不是直接從數據庫工具中建構。並且永遠不要刪除行，而是將它們標記為“已刪除”。這將增加查詢的混亂，因為他們將不得不忽略這些行。
PRIMARY KEY在 MySQL 中，InnoDB 要求每個表都存在唯一性。但這就是要求的程度。鍵甚至可以是字元串。差距對使用者和 DBA 來說是一種便利，**而不是一種不便。
我可以想到一種無間隙會很方便的情況——一次分成 100 行的組。但是有一個簡單的解決方法，使用
LIMIT 100,1.差距對性能的影響為零。這包括非數字索引。和非唯一索引。和綜合指數。
當然，您可能會用完 id。我想我在使用 MySQL 的近 2 年中已經看到過兩次這種情況。我還不如擔心被小行星撞擊。它在我的讓我保持清醒的事情清單上很低。
差距發生在（至少）：、、、、、 （顯式或由於崩潰）、多主複製（包括 Galera 和組複製
INSERT IGNORE）。你真的想為那些想出解決方法嗎？！IODKU``REPLACE``DELETE``ROLLBACK隨意讓我們理智地檢查講師所說的任何其他可疑之處。