在一些中小型項目開發(fā)中，我們通常會使用自增 ID 來作為主鍵的生成策略，但隨著時間的推移，數(shù)據(jù)庫的信息也會越來越多，尤其是使用自增 ID 作為日志表的主鍵生成策略時，可能很快就會遇到 ID 被用完的情況，那么如果發(fā)生了這種情況，MySQL 又會怎樣執(zhí)行呢？

PS：當然，在分庫分表的場景中，我們通常會使用雪花算法來替代自增 ID，但中小型項目開發(fā)中，使用自增 ID 的場景還是比較多的。

1.自增ID

在 MySQL 中，如果字段的數(shù)據(jù)類型為整數(shù)類型（如 INT、BIGINT 等），則可以通過關(guān)鍵字“AUTO_INCREMENT”來設(shè)置讓當前的字段實現(xiàn)自增，例如以下 SQL：

CREATE TABLE example_table (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(128)
);

1.1 優(yōu)點分析

自增 ID 的優(yōu)點如下：

1. 簡單方便，能自動為每行數(shù)據(jù)分配唯一的標識。
2. 對于按順序插入的數(shù)據(jù)，能很好地反映數(shù)據(jù)插入的先后順序。

1.2 缺點分析

自增 ID 的缺點如下：

• 在數(shù)據(jù)進行遷移或分庫分表時，可能會出現(xiàn)問題，需要特殊處理。
• 如果數(shù)據(jù)量非常大，可能會達到自增 ID 的上限。
• 存在安全性問題，比如通過自增 ID 可能會推測出一些業(yè)務信息。例如，一個電商訂單表使用自增 ID 作為主鍵，可能會被競爭對手通過訂單號大致推測出業(yè)務量等信息。

2.自增ID用完會怎樣？

自增 ID 分為以下兩種情況：

圖片

一種是主鍵自增 ID 用完后的情況，另一種是 InnoDB 引擎中未設(shè)置主鍵時使用 row_id 用完后的場景，它們的情況是不一樣的，所以我們分開來聊。

2.1 主鍵自增ID用完

當主鍵自增 ID 達到上限后，再新增下一條數(shù)據(jù)時，它的 ID 不會變（還是最大的值），只是此時再添加數(shù)據(jù)時，因為主鍵約束的原因，ID 是不允許重復的，所以就會報錯提示主鍵沖突。

我們可以使用以下 SQL 來測試：

CREATE TABLE t (
    id INT AUTO_INCREMENT PRIMARY KEY,
    `name` VARCHAR(128)
) auto_increment=2147483647;
insert into t(id,`name`) values(null,'javacn.site');
select * from t;
insert into t(id,`name`) values(null,'www.javacn.site');

以上 SQL 是創(chuàng)建了一個表 t，并且給 t 表的主鍵 id 設(shè)置自增 ID，之后再將表的自增 ID 初始化為 INT（有符號）的最大值 2147483647，然后再添加兩條數(shù)據(jù)。

以上 SQL 的執(zhí)行結(jié)果如下：

圖片

從上面的執(zhí)行結(jié)果可以看出：當主鍵自增 ID 達到上限后，再新增下一條數(shù)據(jù)時，它的 ID 不會變（還是最大的值），只是此時再添加數(shù)據(jù)時，因為主鍵約束的原因，ID 是不允許重復的，所以就會報錯提示主鍵沖突。

2.2 row_id用完

如果表沒有設(shè)置主鍵，InnoDB 會自動創(chuàng)建一個全局隱藏的 row_id，其長度為 6 個字節(jié)，當 row_id 達到上限后，它的執(zhí)行流程和主鍵 ID 不同，它是再次歸零，然后重新遞增，如果出現(xiàn)相同的 row_id，后面的數(shù)據(jù)會覆蓋之前的數(shù)據(jù)。