達到 MySQL 中 ID 的最大限制

Question

在 mySQL 中，我使用主鍵作為 UINT32。 ID 將很快達到 4,294,967,295 的限制。 我的服務是一個節點應用程序。

有效處理這種情況的解決方案是什么？

我在我的節點應用程序中使用 schemapack.js 進行 object 序列化。 無法使用 BIGINT 或 UINT64，因為 schemapack 不支持該數據類型。

此表未在歷史背景下使用。 只有實時服務使用此表。

https://github.com/phretaddin/schemapack#here-is-a-table-of-the-available-data-types-for-use-in-your-schemas

我能想到的方法：

1. 當 ID 接近最大限制的 1% 時創建一個新表。 這種方法的問題是必須有效地通知所有其他服務表名的更改。 它可能導致多個競爭條件和許多故障。 有多個集群運行節點應用程序。

2. 由於此表未在歷史上下文中使用，因此可以用新數據覆蓋舊數據。 達到限制后將 ID 重置為 0 並覆蓋舊記錄。

3. 達到限制后，刪除表的一部分。 將表划分為段，每次達到限制時使用隊列方法刪除段（先進先出）。

Answer 1

說出適合您情況的最佳方法是非常主觀的。 這是關於為您的應用程序/設置權衡不同解決方案的優缺點。

我不熟悉 schemapack，但我猜 32 位 integer 限制源於 JS 本身不支持 64 位整數的事實（盡管BigInt正在解決這個問題）。 傳統的Number JS 類型可用於高達 53 位的整數而不會犧牲精度，但這並不完全是 64 位。

如果需要在 JS 中支持 64 位整數，可以使用字符串類型。 它肯定會更慢，但對於您的特定情況，這可能不明顯/不重要。 編碼為字符串/varchars 的整數可能會占用更多空間（您可以考慮將這些整數編碼為 HEX，這將比標准十進制表示更節省空間，但同時相對方便）。 這種方法也更容易出錯。 總的來說，如果您不能或不想使用BigInt ，如果您需要處理更大的數字，字符串可能是一個合理的解決方法。