mysql三張表關(guān)聯(lián)查詢 mysql表數(shù)據(jù)量太大,達到了1億多條數(shù)據(jù),除了分庫分表之外,還有沒有其他的解決方式?
mysql表數(shù)據(jù)量太大,達到了1億多條數(shù)據(jù),除了分庫分表之外,還有沒有其他的解決方式?mysql在常規(guī)配置下,一般只能承受2000萬的數(shù)據(jù)量(同時讀寫,且表中有大文本字段,單臺服務器)。現(xiàn)在超過1億,
mysql表數(shù)據(jù)量太大,達到了1億多條數(shù)據(jù),除了分庫分表之外,還有沒有其他的解決方式?
mysql在常規(guī)配置下,一般只能承受2000萬的數(shù)據(jù)量(同時讀寫,且表中有大文本字段,單臺服務器)?,F(xiàn)在超過1億,并不斷增加的情況下,建議如下處理:
1 分表。可以按時間,或按一定的規(guī)則拆分,做到查詢某一條數(shù)據(jù)庫,盡量在一個子表中即可。這是最有效的方法
2 讀寫分離。尤其是寫入,放在新表中,定期進行同步。如果其中記錄不斷有update,最好將寫的數(shù)據(jù)放在 redis中,定期同步
3 表的大文本字段分離出來,成為獨立的新表。大文本字段,可以使用NOSQL數(shù)據(jù)庫
4 優(yōu)化架構(gòu),或優(yōu)化SQL查詢,避免聯(lián)表查詢,盡量不要用count(*), in,遞歸等消耗性能的語句
5 用內(nèi)存緩存,或在前端讀的時候,增加緩存數(shù)據(jù)庫。重復讀取時,直接從緩存中讀取。
上面是低成本的管理方法,基本幾臺服務器即可搞定,但是管理起來麻煩一些。
當然,如果整體數(shù)據(jù)量特別大的話,也不在乎投入費用的話,用集群吧,用TIDB吧
mysql一張大表,一張小表,如何join最快?
rows代表這個步驟相對上一步結(jié)果的每一行需要掃描的行數(shù),可以看到這個sql需要掃描的行數(shù)為35773*8134,非常大的一個數(shù)字。本來c和h表的記錄條數(shù)分別為40000 和10000 ,這幾乎是兩個表做笛卡爾積的開銷了(select * from c,h)。
于是我上網(wǎng)查了下MySQL實現(xiàn)join的原理,原來MySQL內(nèi)部采用了一種叫做 nested loop join的算法。Nested Loop Join 實際上就是通過驅(qū)動表的結(jié)果集作為循環(huán)基礎數(shù)據(jù),然后一條一條的通過該結(jié)果集中的數(shù)據(jù)作為過濾條件到下一個表中查詢數(shù)據(jù),然后合并結(jié)果。如果還有第三個參與 Join,則再通過前兩個表的 Join 結(jié)果集作為循環(huán)基礎數(shù)據(jù),再一次通過循環(huán)查詢條件到第三個表中查詢數(shù)據(jù),如此往復,基本上MySQL采用的是最容易理解的算法來實現(xiàn)join。所以驅(qū)動表的選擇非常重要,驅(qū)動表的數(shù)據(jù)小可以顯著降低掃描的行數(shù)。
mysql4.0中一表關(guān)聯(lián)多表左連接sql寫法?
mysql4.0中一表關(guān)聯(lián)多表左連接sql寫法: select m.zsbt,br.brand_name,b.bname from merchant m left join brand br on m.probrand=br.brand_id left join base_source b on m.zsdz=b.bid