當 mysql 單錶記錄數過大時，增刪改查效能都會急劇下降，可以參考以下步驟來優化。
單錶優化
除非單錶資料未來會一直不斷**，否則不要一開始就考慮拆分，拆分會帶來邏輯、部署、運維的各種複雜度，一般以整型值為主的表在千萬級以下，字串為主的表在五百萬以下是沒有太大問題的。而事實上很多時候 mysql 單錶的效能依然有不少優化空間，甚至能正常支撐千萬級以上的資料量：
字段
盡量使用tinyint、smallint、medium_int作為整數型別而非int，如果非負則加上unsigned；
varchar的長度只分配真正需要的空間；
使用列舉或整數代替字串型別；
盡量使用timestamp而非datetime；
單錶不要有太多字段，建議在 20 以內；
避免使用 null 字段，很難查詢優化且占用額外索引空間；
用整型來存 ip。
索引
索引並不是越多越好，要根據查詢有針對性的建立，考慮在where和order by命令上涉及的列建立索引，可根據explain來檢視是否用了索引還是全表掃瞄；
應盡量避免在where子句中對字段進行null值判斷，否則將導致引擎放棄使用索引而進行全表掃瞄；
值分布很稀少的字段不適合建索引，例如 "性別" 這種只有兩三個值的字段；
字元欄位只建字首索引；
字元字段最好不要做主鍵；
不用外來鍵，由程式保證約束；
盡量不用unique，由程式保證約束；
使用多列索引時主意順序和查詢條件保持一致，同時刪除不必要的單列索引。
查詢 sql
可通過開啟慢查詢日誌來找出較慢的 sql；
不做列運算：select id where age + 1 = 10，任何對列的操作都將導致表掃瞄，它包括資料庫教程函式、計算表示式等等，查詢時要盡可能將操作移至等號右邊；
sql 語句盡可能簡單：一條 sql 只能在乙個 cpu 運算；大語句拆小語句，減少鎖時間；一條大 sql 可以堵死整個庫；
不用select *；
or改寫成in：or的效率是 n 級別，in的效率是 log(n) 級別，in 的個數建議控制在 200 以內；
不用函式和觸發器，在應用程式實現；
避免%***式查詢；
少用join；
MySQL大表優化方案
cubrid 但其工業品質和mysql尚有差距，且需要較大的運維投入，如果想將原始的mysql遷移到可水平擴充套件的新資料庫中，可以考慮一些雲資料庫 阿里雲petadata 阿里雲oceanbase nosql 在mysql上做sharding是一種戴著鐐銬的跳舞，事實上很多大表本身對mysql這種...
MySQL大表優化方案
阿里雲rds for mysql mysql5.7版本 資料庫業務表每月新增資料量超過千萬,隨著資料量持續增加,我們業務出現大表慢查詢,在業務高峰期主業務表的慢查詢需要幾十秒嚴重影響業務 mysql資料庫本身高度靈活，造成效能不足，嚴重依賴開發人員的表設計能力以及索引優化能力,在這裡給幾點優化建議 ...
mysql八大優化方案
1 選最實用的字段屬性 建立表的時候，為了獲得更好的效能，可以將表中字段的寬度設定的盡可能小。盡量把字段設定為not null,這樣在執行查詢時，資料庫不用比較null值。對於一些文字字段，例如 省份 性別 可以定義為enum型別。在mysql中，enum型別被當作數值型資料處理，數值型資料處理速度...