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

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

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

SQL查詢的執行路徑：

sql優化

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

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

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

4. 禁止使用!=、<>、OR等操作符，會導致全表掃描

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

6. 禁止使用isnull、isnotnull等空判斷，會導致全表掃描

7. 禁止使用select*，應該明確指定要查詢的列，避免大批量數據傳輸、磁盤讀寫

8. 用exist代替in

9. 禁止大表連接查詢

結構優化

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

一主多從，讀寫分離，緩存

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

分區分表

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

以上，純屬扯淡！回到題主的問題，簡單粗暴的方案是啥？數據庫內存加大！128G、256G上！硬盤采用SSD！一主多從、讀寫分離，借助阿里云RDS輕松完成，有錢就可以了，分區分表？那就不叫簡單粗暴了！幾千萬數據？soeasy！

大家有什么好的簡單粗暴的方案？歡迎評論區交流討論～