問(wèn)答專欄Q & A COLUMN
當(dāng)一張表的數(shù)據(jù)量達(dá)到千萬(wàn)級(jí)別的時(shí)候，任何對(duì)表的操作都得小心翼翼。核心點(diǎn)在于避免全表掃描、避免鎖表、避免產(chǎn)生大量行鎖。
本質(zhì)上是讓每一次sql的執(zhí)行都更快的完成，避免過(guò)長(zhǎng)時(shí)間占用數(shù)據(jù)庫(kù)連接，讓連接能夠迅速的釋放回?cái)?shù)據(jù)庫(kù)連接池，提供更多穩(wěn)定的服務(wù)。
一旦產(chǎn)生大量的行鎖甚至表鎖，將會(huì)帶來(lái)連接瞬間被打滿、數(shù)據(jù)庫(kù)資源耗盡、服務(wù)宕機(jī)的災(zāi)難性后果。所以如何避免以上問(wèn)題的發(fā)生才是最重要的，絕不能等問(wèn)題發(fā)生之后再去解決。
SQL查詢的執(zhí)行路徑：
所有sql必須命中索引，禁止全表掃描
禁止like查詢，會(huì)導(dǎo)致全表掃描
where條件必須符合最左前綴查詢?cè)瓌t，會(huì)無(wú)法命中索引，全表掃描
禁止使用!=、<>、OR等操作符，會(huì)導(dǎo)致全表掃描
禁止參與列運(yùn)算例如：sum、date_format，會(huì)導(dǎo)致全表掃描
禁止使用is null、is not null等空判斷，會(huì)導(dǎo)致全表掃描
禁止使用select *，應(yīng)該明確指定要查詢的列，避免大批量數(shù)據(jù)傳輸、磁盤讀寫
用exist代替in
禁止大表連接查詢
避免大字段和核心數(shù)據(jù)存儲(chǔ)在一張表，可以考慮將大字段拆出來(lái)存儲(chǔ)到OSS、ES、openSearch等數(shù)據(jù)源中，通過(guò)主鍵關(guān)聯(lián)的形式查詢。
主從配置可以支持更多的數(shù)據(jù)連接，避免了單機(jī)連接不足的問(wèn)題，讀寫分離可以讓讀業(yè)務(wù)走從庫(kù)，不同的業(yè)務(wù)走不同的數(shù)據(jù)庫(kù)，比如報(bào)表業(yè)務(wù)。
分區(qū)分表基本上就是終極方案了，水太深，這里不細(xì)說(shuō)了。
以上，純屬扯淡！回到題主的問(wèn)題，簡(jiǎn)單粗暴的方案是啥？數(shù)據(jù)庫(kù)內(nèi)存加大！128G、256G上！硬盤采用SSD！一主多從、讀寫分離，借助ucloud云RDS輕松完成，有錢就可以了，分區(qū)分表？那就不叫簡(jiǎn)單粗暴了！幾千萬(wàn)數(shù)據(jù)？so easy！
大家有什么好的簡(jiǎn)單粗暴的方案？歡迎評(píng)論區(qū)交流討論～
評(píng)論0
加載中...
千萬(wàn)級(jí)大表在不考慮分庫(kù)分表的情況下有如下幾個(gè)可以優(yōu)化的地方，僅供參考：
主鍵最好是遞增的，不要用uuid，降低空間占用；
根據(jù)需要查詢的字段，建立合適的索引（包括聯(lián)合索引），必要的時(shí)候根據(jù)explain查看執(zhí)行計(jì)劃分析索引是否被命中
根據(jù)查詢條件，刪掉一些命中率比較低的索引，提高數(shù)據(jù)插入效率；
對(duì)于一些復(fù)雜查詢，比如order by、group by等，要注意執(zhí)行計(jì)劃的Extra列是否有Using temporary字樣，如果有的話就意味著使用了臨時(shí)表，這種查詢的頻率比較高的話，可以適當(dāng)增大內(nèi)存臨時(shí)表空間，可以提高查詢速度；
對(duì)于這種大數(shù)據(jù)量的表，查詢語(yǔ)句不要使用自動(dòng)生成的那種，盡量手寫SQL，提高執(zhí)行效率并且避免一些無(wú)用字段的查詢，盡可能的去使用索引。下面是幾句寫SQL常用口訣：
全值匹配我最愛(ài)，最左前綴要遵守；
帶頭大哥不能死，中間兄弟不能斷；
索引列上不計(jì)算，范圍之后全失效；
萊克百分寫最左，覆蓋索引不寫星；
不等空值還有噢，索引失效要少用。
如果說(shuō)你們的查詢比較頻繁，并且比較復(fù)雜，摻雜了大量的模糊查詢以及統(tǒng)計(jì)查詢，建議把數(shù)據(jù)同步放到 es（Elasticsearch）里面一份，這樣問(wèn)題就解決了。
以上僅供參考，歡迎大家在評(píng)論區(qū)留言溝通交流！
評(píng)論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答1
回答
