mysql上億數(shù)據(jù)秒級(jí)查詢 為什么MySQL在數(shù)據(jù)庫(kù)較大的時(shí)候分頁查詢很慢,如何優(yōu)化?
為什么MySQL在數(shù)據(jù)庫(kù)較大的時(shí)候分頁查詢很慢,如何優(yōu)化?正如房東所說,分頁查詢?cè)谖覀兊膶?shí)際應(yīng)用中非常常見,也是問題最多的查詢場(chǎng)景。例如,對(duì)于下面的簡(jiǎn)單語句,通常的思考方式是在name、age、reg
為什么MySQL在數(shù)據(jù)庫(kù)較大的時(shí)候分頁查詢很慢,如何優(yōu)化?
正如房東所說,分頁查詢?cè)谖覀兊膶?shí)際應(yīng)用中非常常見,也是問題最多的查詢場(chǎng)景。例如,對(duì)于下面的簡(jiǎn)單語句,通常的思考方式是在name、age、register中u在time字段上創(chuàng)建一個(gè)復(fù)合索引。這樣,條件排序可以有效地利用索引,性能得到快速提高。
如上例所示,當(dāng)limit子句變?yōu)椤發(fā)imit 100000,50”時(shí),我們會(huì)發(fā)現(xiàn),如果只選擇了50條語句,為什么會(huì)變慢?
,所以我們會(huì)覺得很慢。
在大數(shù)據(jù)情況下MySQL的一種簡(jiǎn)單分頁優(yōu)化方法?
直接使用數(shù)據(jù)庫(kù)提供的SQL語句風(fēng)格:在mysql中,可以使用以下方法:select*from table name limit M.N---適應(yīng)情況:適合數(shù)據(jù)量小(元組百/千)的情況-原因/缺點(diǎn):全表掃描,速度會(huì)非常慢,一些數(shù)據(jù)庫(kù)結(jié)果集返回不穩(wěn)定(例如,一次返回1、2、3,另一次返回2、1、3)。Limit limits是從結(jié)果集的M位置獲取n個(gè)輸出,而discard rest limits本質(zhì)上是服務(wù)器端的一次掃描。最后一個(gè)查詢是掃描,它包含1000萬個(gè)數(shù)據(jù)。即使掃描的索引是幾十萬個(gè)磁盤塊,當(dāng)然也很慢
如果是引導(dǎo)數(shù)據(jù),考慮光標(biāo)
如果是在界面上顯示的,可以先考慮優(yōu)化查詢場(chǎng)景,因?yàn)?000W數(shù)據(jù)在頁面上顯示的情況很少,優(yōu)化后通常是最多1W頁,即大約10W的數(shù)據(jù)。在設(shè)計(jì)合理和索引命中的情況下,偏移量限制還是很快的
在正常配置下,MySQL只能承載2000萬數(shù)據(jù)(同時(shí)讀寫,表中有大的文本字段,單臺(tái)服務(wù)器)。現(xiàn)在已經(jīng)超過1億,而且還在增加,建議按以下方式處理:
1子表。它可以按時(shí)間或一定的規(guī)則進(jìn)行拆分,以便盡可能地查詢子表中的數(shù)據(jù)庫(kù)。這是最有效的方法。特別是寫,放入一個(gè)新表,并定期同步。如果記錄不斷更新,最好將寫入的數(shù)據(jù)放在redis中,并定期同步表3的大文本字段,將它們分隔成一個(gè)新的獨(dú)立表。對(duì)于較大的文本字段,可以使用NoSQL數(shù)據(jù)庫(kù)
4優(yōu)化體系結(jié)構(gòu),或者優(yōu)化SQL查詢,避免聯(lián)合表查詢,盡量不要使用count(*)、in、recursion等性能消耗語句
5使用內(nèi)存緩存,或者在前端讀取時(shí)增加緩存數(shù)據(jù)庫(kù)。重復(fù)讀取時(shí),直接從緩存中讀取。
以上是一種低成本的管理方法,基本上幾個(gè)服務(wù)器就可以做到,但是管理起來有點(diǎn)麻煩。
當(dāng)然,如果總體數(shù)據(jù)量特別大,并且您不關(guān)心投資成本,請(qǐng)使用集群或tidb