數(shù)據(jù)庫自增 ID

搞一個數(shù)據(jù)庫，什么也不干，就用于生成主鍵。

你的系統(tǒng)里每次得到一個 id，都需要往那個專門生成主鍵的數(shù)據(jù)庫中通過插入獲取一個自增的ID，拿到這個 id 之后再往對應的分庫分表里去寫入。

優(yōu)點：方便簡單。

缺點：單庫生成自增 id，要是高并發(fā)的話，就會有瓶頸的；如果你硬是要改進一下，那么就專門開一個服務出來，這個服務每次就拿到當前 id 最大值，然后自己遞增幾個 id，一次性返回一批 id，然后再把當前最大 id 值修改成遞增幾個 id 之后的一個值；但是無論如何都是基于單個數(shù)據(jù)庫。

適合的場景：系統(tǒng)并發(fā)不大，只是因為數(shù)據(jù)量大的原因而去做的分庫分表的話，可以采用這種方式。

設置數(shù)據(jù)庫 sequence 或者表自增字段步長

可以通過設置數(shù)據(jù)庫 sequence 或者表的自增字段步長來進行水平伸縮。

比如說，現(xiàn)在有 8 個服務節(jié)點，每個服務節(jié)點使用一個 sequence 功能來產(chǎn)生 ID，每個 sequence 的起始 ID 不同，并且依次遞增，步長都是8

適合的場景：在用戶防止產(chǎn)生的 ID 重復時，這種方案實現(xiàn)起來比較簡單，也能達到性能目標。但是服務節(jié)點固定，步長也固定，將來如果還要增加服務節(jié)點，就不好搞了。

UUID

優(yōu)點：本地生成，不需要基于數(shù)據(jù)庫；

缺點：UUID 太長了、占用空間大；作為主鍵性能太差：UUID 不具有有序性，會導致 B+ 樹索引在寫的時候有過多的隨機寫操作（連續(xù)的 ID 可以產(chǎn)生部分順序寫），還有，由于在寫的時候不能產(chǎn)生有順序的 append 操作，而需要進行 insert 操作，導致頻繁的進行頁分裂，性能下降明顯。

適合的場景：如果你是要隨機生成個什么文件名、編號之類的，你可以用 UUID，但是作為InnoDB表的主鍵是不能用 UUID 的。

UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf

系統(tǒng)當前時間戳+XXX

適合的場景：一般如果用這個方案，是將當前時間戳跟很多其他的業(yè)務字段拼接起來，作為一個 id，如果業(yè)務上你覺得可以接受，那么也是可以的。你可以將別的業(yè)務字段值跟當前時間拼接起來，組成一個全局唯一的編號。

Snowflake 算法

snowflake 算法是 twitter 開源的分布式 id 生成算法，采用 Scala 語言實現(xiàn)，是把一個 64 位的 long 型的 id，1 個 bit 是不用的，用其中的 41 bit 作為時間戳（毫秒數(shù)），用 10 bit 作為工作機器 id，12 bit 作為序列號。

• 1 bit：不用，為啥呢？因為二進制里第一個 bit 為如果是 1，那么都是負數(shù)，但是我們生成的 id 都是正數(shù)，所以第一個 bit 統(tǒng)一都是 0。
• 41 bit：表示的是時間戳，單位是毫秒。41 bit 可以表示的數(shù)字多達 2^41 - 1，也就是可以標識 2^41 - 1 個毫秒值，換算成年就是表示69年的時間。
• 10 bit：記錄工作機器 id，代表的是這個服務最多可以部署在 2^10臺機器上哪，也就是1024臺機器。但是 10 bit 里 5 個 bit 代表機房 id，5 個 bit 代表機器 id。意思就是最多代表 2^5個機房（32個機房），每個機房里可以代表 2^5 個機器（32臺機器）。
• 12 bit：這個是用來記錄同一個毫秒內產(chǎn)生的不同 id，12 bit 可以代表的最大正整數(shù)是 2^12 - 1 = 4096，也就是說可以用這個 12 bit 代表的數(shù)字來區(qū)分同一個毫秒內的 4096 個不同的 id。

0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000

到此這篇關于Mysql分庫分表之后主鍵處理的幾種方法的文章就介紹到這了,更多相關Mysql分庫分表主鍵內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論