MySQL分庫分表之后，id主鍵如何處理？我從分庫分表存在的問題和怎么做來回答一下這個問題。。一，分庫分表的ID主鍵不能依賴于數(shù)據(jù)庫的自增，因為多庫中會重復！通常使用外接的數(shù)據(jù)組件獲取全局唯一的ID：

MySQL分庫分表之后，id主鍵如何處理？

我從分庫分表存在的問題和怎么做來回答一下這個問題。。

一，分庫分表的ID主鍵不能依賴于數(shù)據(jù)庫的自增，因為多庫中會重復！

通常使用外接的數(shù)據(jù)組件獲取全局唯一的ID：比如加強型UUID（根據(jù)Ip，時間戳等得到）和使用Redis(RedisAtomicLong)和zookeeper的API獲取，Twitter的雪花算法等等！

二，分庫分表之后的連接查詢比較困難！

問題沒法避免，通常拆分SQL，使用多次查詢，用查到的結果再分別查別的結果！

三，分布式事務的數(shù)據(jù)一致性很難保證！

可以使用TCC編程模型保證兩處的事務都能正確提交，但是這種方式對代碼的侵入比較重！也可以使用基于消息的數(shù)據(jù)一致性保證！

四，多數(shù)據(jù)的排序，分組，統(tǒng)計會比較困難！

1，用多線程，對多個節(jié)點分別查詢，然后匯總！

2，也可以提前冗余查詢表，將所有的經(jīng)常查詢的重點數(shù)據(jù)提前統(tǒng)一到個庫表里！

分庫分表涉及到的知識點比較多，建議使用專門的分庫分表組件！本人有mycat使用經(jīng)驗，如果您有相關問題，歡迎前來探討！

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

謝謝邀請！這個問題跟具體業(yè)務場景和技術實現(xiàn)有關：

1、業(yè)務場景：例如訂單、支付單號等比較敏感的肯定不能自增了，都是安全級別很高的字段，需要唯一id作為主鍵。

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

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

分布式ID常見的兩種方法就是UUID和snowflake算法（雪花算法）。

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

snowflake算法是twitter開源的分布式ID生成算法，其核心思想是一個long型的ID：1位標識符（始終是0）、41位時間戳毫秒數(shù)、10位機器標識碼、12位毫秒內(nèi)序列號，該算法單機每秒內(nèi)理論上最多可以生成1000*(2^12)的ID，性能高、趨勢遞增、靈活度高，但snowflake依賴機器的時鐘，如果服務器時鐘回撥會導致生成重復的ID。