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