redis生成全局自增id MySQL分庫(kù)分表之后,id主鍵如何處理?
MySQL分庫(kù)分表之后,id主鍵如何處理?我將從存在的問(wèn)題和如何做中回答這個(gè)問(wèn)題。。沒(méi)有辦法避免這個(gè)問(wèn)題,通常拆分SQL,使用多個(gè)查詢(xún),然后使用結(jié)果分別檢查結(jié)果!我們可以使用TCC編程模型來(lái)確保兩個(gè)事
MySQL分庫(kù)分表之后,id主鍵如何處理?
我將從存在的問(wèn)題和如何做中回答這個(gè)問(wèn)題。。
沒(méi)有辦法避免這個(gè)問(wèn)題,通常拆分SQL,使用多個(gè)查詢(xún),然后使用結(jié)果分別檢查結(jié)果
!我們可以使用TCC編程模型來(lái)確保兩個(gè)事務(wù)可以正確提交,但這種代碼入侵方式相對(duì)較重!您還可以使用基于消息的數(shù)據(jù)一致性保證
!1. 使用多線程分別查詢(xún)多個(gè)節(jié)點(diǎn),然后匯總
全局唯一ID在分布式系統(tǒng)中用來(lái)做什么用?
請(qǐng)問(wèn)對(duì)于數(shù)據(jù)庫(kù)的主鍵究竟要不要用自增id呢?
感謝您的邀請(qǐng)!此問(wèn)題與特定的業(yè)務(wù)場(chǎng)景和技術(shù)實(shí)現(xiàn)有關(guān):
1。業(yè)務(wù)場(chǎng)景:如訂單、付款單等敏感字段不能自動(dòng)添加。它們是具有高安全級(jí)別的字段,需要一個(gè)唯一的ID作為主鍵。
2. 技術(shù)實(shí)現(xiàn):在實(shí)際開(kāi)發(fā)過(guò)程中,批量導(dǎo)入或處理數(shù)據(jù)時(shí),需要考慮技術(shù)實(shí)現(xiàn)的性能,因此需要從多方面驗(yàn)證是使用自增主鍵還是非自增主鍵。
mysql表數(shù)據(jù)量太大,達(dá)到了1億多條數(shù)據(jù),除了分庫(kù)分表之外,還有沒(méi)有其他的解決方式?
在正常配置下,MySQL只能承載2000萬(wàn)數(shù)據(jù)(同時(shí)讀寫(xiě),表中有大文本字段,單服務(wù)器)。現(xiàn)在已經(jīng)超過(guò)1億,而且還在增加,建議按以下方式處理:
1子表。它可以按時(shí)間或一定的規(guī)則進(jìn)行拆分,以便盡可能地查詢(xún)子表中的數(shù)據(jù)庫(kù)。這是最有效的方法。特別是寫(xiě),放入一個(gè)新表,并定期同步。如果記錄不斷更新,最好將寫(xiě)入的數(shù)據(jù)放在redis中,并定期同步表3的大文本字段,將它們分隔成一個(gè)新的獨(dú)立表。對(duì)于較大的文本字段,可以使用NoSQL數(shù)據(jù)庫(kù)
4優(yōu)化體系結(jié)構(gòu),或者優(yōu)化SQL查詢(xún),避免聯(lián)合表查詢(xún),盡量不要使用count(*)、in、recursion等性能消耗語(yǔ)句
5使用內(nèi)存緩存,或者在前端讀取時(shí)增加緩存數(shù)據(jù)庫(kù)。重復(fù)讀取時(shí),直接從緩存中讀取。
以上是一種低成本的管理方法,基本上幾個(gè)服務(wù)器就可以做到,但是管理起來(lái)有點(diǎn)麻煩。
當(dāng)然,如果總體數(shù)據(jù)量特別大,并且您不關(guān)心投資成本,請(qǐng)使用集群或tidb