請(qǐng)問(wèn)對(duì)于數(shù)據(jù)庫(kù)的主鍵究竟要不要用自增id呢？謝謝邀請(qǐng)！這個(gè)問(wèn)題跟具體業(yè)務(wù)場(chǎng)景和技術(shù)實(shí)現(xiàn)有關(guān)：1、業(yè)務(wù)場(chǎng)景：例如訂單、支付單號(hào)等比較敏感的肯定不能自增了，都是安全級(jí)別很高的字段，需要唯一id作為主鍵。2

請(qǐng)問(wèn)對(duì)于數(shù)據(jù)庫(kù)的主鍵究竟要不要用自增id呢？

謝謝邀請(qǐng)！這個(gè)問(wèn)題跟具體業(yè)務(wù)場(chǎng)景和技術(shù)實(shí)現(xiàn)有關(guān)：

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

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

MySQL分庫(kù)分表之后，id主鍵如何處理？

我從分庫(kù)分表存在的問(wèn)題和怎么做來(lái)回答一下這個(gè)問(wèn)題。。

一，分庫(kù)分表的ID主鍵不能依賴(lài)于數(shù)據(jù)庫(kù)的自增，因?yàn)槎鄮?kù)中會(huì)重復(fù)！

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

二，分庫(kù)分表之后的連接查詢(xún)比較困難！

問(wèn)題沒(méi)法避免，通常拆分SQL，使用多次查詢(xún)，用查到的結(jié)果再分別查別的結(jié)果！

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

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

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

1，用多線(xiàn)程，對(duì)多個(gè)節(jié)點(diǎn)分別查詢(xún)，然后匯總！

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

分庫(kù)分表涉及到的知識(shí)點(diǎn)比較多，建議使用專(zhuān)門(mén)的分庫(kù)分表組件！本人有mycat使用經(jīng)驗(yàn)，如果您有相關(guān)問(wèn)題，歡迎前來(lái)探討！