請問對于數(shù)據(jù)庫的主鍵究竟要不要用自增id呢？謝謝你的邀請！此問題與特定的業(yè)務場景和技術(shù)實現(xiàn)有關(guān)：1。業(yè)務場景：如訂單、付款單等敏感字段不能自動添加。它們是具有高安全級別的字段，需要一個唯一的ID作為主

請問對于數(shù)據(jù)庫的主鍵究竟要不要用自增id呢？

謝謝你的邀請！此問題與特定的業(yè)務場景和技術(shù)實現(xiàn)有關(guān)：

1。業(yè)務場景：如訂單、付款單等敏感字段不能自動添加。它們是具有高安全級別的字段，需要一個唯一的ID作為主鍵。

2. 技術(shù)實現(xiàn)：在實際開發(fā)過程中，批量導入或處理數(shù)據(jù)時，需要考慮技術(shù)實現(xiàn)的性能，因此需要從多方面驗證是使用自增主鍵還是非自增主鍵。

在分布式系統(tǒng)中，如何生成分布式ID？

兩種常用的分布式ID方法是UUID和snowflake算法。

UUID是一種本地ID生成方法，不需要遠程調(diào)用，具有高性能、低延遲和良好的可擴展性，但UUID不支持增量。

該算法的核心思想是一個長ID：1位標識符（始終為0）、41位時間戳毫秒、10位機器識別碼和12位序列號（毫秒）。從理論上講，該算法可以在一臺機器上每秒生成1000*（2^12）個ID，具有高性能、增長趨勢和高靈活性。然而，算法依賴于機器的操作時鐘。如果服務器倒計時，將生成重復的ID。

全局唯一ID在分布式系統(tǒng)中用來做什么用？

雖然UUID生成世界上唯一的ID，但它是非數(shù)字的，沒有順序。其中大部分數(shù)據(jù)需要存儲在數(shù)據(jù)庫中。數(shù)據(jù)庫中的熱數(shù)據(jù)存儲在內(nèi)存中，查詢效率高。如果順序不對，查詢將需要在內(nèi)存和硬盤之間進行翻轉(zhuǎn)，這將影響速度。另外，為了便于閱讀，一般采用全數(shù)字。如果不要求ID是數(shù)字，建議使用最簡單的一個，即UUID，它包括機器碼、時間戳、隨機數(shù)等，但UUID最終生成一個全局唯一的字符串，而不是整數(shù)，看起來很混亂。

2. MySQL自己添加ID。它使用一個表來存儲各種業(yè)務id。每個分布式系統(tǒng)插入一個ID后，生成1000萬個本地號碼與ID拼接，然后每個系統(tǒng)得到一個ID，相當于生成1000萬個ID，足夠長時間使用。這1000萬個ID可以預先定義，并在系統(tǒng)啟動時放入內(nèi)存。因為它們只是ID，所以不會占用太多內(nèi)存。MySQL可以內(nèi)置到集群中，這不會影響自增IDs的使用。

3. 與MySQL的auto-increment ID類似，redis的incr實現(xiàn)了自動增量。每個分布式系統(tǒng)，比如redis，都是用incr插入一個ID，然后生成1000萬個本地號碼與ID拼接，如果每個系統(tǒng)都有一個ID，相當于生成1000萬個ID，足夠長時間使用。這1000萬個ID可以預先定義，并在系統(tǒng)啟動時放入內(nèi)存。因為它只是一個ID，所以不會占用太多內(nèi)存。Redis也可以內(nèi)置到集群中，這不會影響自增ID的使用。Twitter的雪花算法與UUID類似，包括機器碼、時間戳、隨機數(shù)等，但最終生成的是64位整數(shù)，可以滿足許多分布式系統(tǒng)的要求。如果Id必須是整數(shù)，建議使用snowflake而不是UUID。