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