當一張表的資料量達到千萬級別的時候，任何對錶的操作都得小心翼翼。核心點在於避免全表掃描、避免鎖表、避免產生大量行鎖。

本質上是讓每一次sql的執行都更快的完成，避免過長時間佔用資料庫連線，讓連線能夠迅速的釋放回資料庫連線池，提供更多穩定的服務。

一旦產生大量的行鎖甚至表鎖，將會帶來連線瞬間被打滿、資料庫資源耗盡、服務宕機的災難性後果。所以如何避免以上問題的發生才是最重要的，絕不能等問題發生之後再去解決。

SQL查詢的執行路徑：

所有sql必須命中索引，禁止全表掃描

禁止like查詢，會導致全表掃描

where條件必須符合最左字首查詢原則，會無法命中索引，全表掃描

禁止使用!=、<>、OR等運算子，會導致全表掃描

禁止參與列運算例如：sum、date_format，會導致全表掃描

禁止使用is null、is not null等空判斷，會導致全表掃描

禁止使用select *，應該明確指定要查詢的列，避免大批次資料傳輸、磁碟讀寫

用exist代替in

禁止大表連線查詢

避免大欄位和核心資料儲存在一張表，可以考慮將大欄位拆出來儲存到OSS、ES、openSearch等資料來源中，透過主鍵關聯的形式查詢。

主從配置可以支援更多的資料連線，避免了單機連線不足的問題，讀寫分離可以讓讀業務走從庫，不同的業務走不同的資料庫，比如報表業務。

分割槽分表基本上就是終極方案了，水太深，這裡不細說了。

以上，純屬扯淡！回到題主的問題，簡單粗暴的方案是啥？資料庫記憶體加大！128G、256G上！硬碟採用SSD！一主多從、讀寫分離，藉助阿里雲RDS輕鬆完成，有錢就可以了，分割槽分表？那就不叫簡單粗暴了！幾千萬資料？so easy！

千萬級大表在不考慮分庫分表的情況下有如下幾個可以最佳化的地方，僅供參考：

主鍵最好是遞增的，不要用uuid，降低空間佔用；

根據需要查詢的欄位，建立合適的索引（包括聯合索引），必要的時候根據explain檢視執行計劃分析索引是否被命中

根據查詢條件，刪掉一些命中率比較低的索引，提高資料插入效率；

對於一些複雜查詢，比如order by、group by等，要注意執行計劃的Extra列是否有Using temporary字樣，如果有的話就意味著使用了臨時表，這種查詢的頻率比較高的話，可以適當增大記憶體臨時表空間，可以提高查詢速度；

對於這種大資料量的表，查詢語句不要使用自動生成的那種，儘量手寫SQL，提高執行效率並且避免一些無用欄位的查詢，儘可能的去使用索引。下面是幾句寫SQL常用口訣：

全值匹配我最愛，最左字首要遵守；

帶頭大哥不能死，中間兄弟不能斷；

索引列上不計算，範圍之後全失效；

萊克百分寫最左，覆蓋索引不寫星；

不等空值還有噢，索引失效要少用。

如果說你們的查詢比較頻繁，並且比較複雜，摻雜了大量的模糊查詢以及統計查詢，建議把資料同步放到 es（Elasticsearch）裡面一份，這樣問題就解決了。