系统优化怎么做-SQL优化
前言
數據庫很重要!很重要!很重要! 重要的事情說三遍。所以單獨用一篇來講述SQL怎么優化。不過這里說到一點,不建議在業務代碼里寫很多復雜業務SQL,基本盡可能的減少 join,子查詢 等,也就說盡量在應用層來解決問題,降低產生低效SQL的概率,數據庫只是完成數據存儲及最簡單查詢的組件。
SQL優化
主要4個方向,以下4個方向盡可能達到了,SQL的執行效率就提高了。
發現慢SQL
DBA開啟MySQL的慢查詢日志,對每日數據庫慢查詢進行監控。慢查詢后每日匯總提供開發進行處理。DBA給出指導意見。
分析執行計劃
主要看對SQL的執行過程中
得到結果是
其中 table 表示是哪個表的數據。
- type比較重要。表示鏈接的類型。鏈接類型由好到壞的,依次是 system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL 一般情況,至少要達到 range 級別,最好是 ref 級別。否則可能會有性能問題。
- possible_keys 是指可以應用到該表的索引,如果為NULL則沒有。
- key 是指用到的索引。
- key_len 是索引的長度,在不影響查詢精度的情況下,值越小越好。
- ref 是指索引的那一列被使用了。一般會是個常數。
- rows 是指有多少行。
- extra 是指額外的信息。也是比較重要的。如果值為 distinct ,說明mysql 找到了域行聯合匹配的行,就不再查找了。
SQL優化實例
- 分頁查詢
第一種分頁寫法
原理:
一次性根據過濾條件取出所有字段進行排序返回。
數據訪問開銷=索引IO + 索引全部記錄結果對應的表數據IO
缺點:
該種寫法越翻到后面執行效率越差,時間越長,尤其表數據量很大的時候。適用場景:當中間結果集很小(10000行以下)或者查詢條件復雜(指涉及多個不同查詢字段或者多表連接)時適用。
第二種分頁寫法:
select t.* from (select id from twhere thread_id = 771025 and deleted = 0 order by gmt_create asc limit 0, 15) a, t where a.id = t.id;前提:
假設t表主鍵是id列,且有聯合索引secondary key:(thread_id, deleted, gmt_create)
原理:
先根據過濾條件利用聯合索引取出主鍵id進行排序,并內部的子查詢只掃描了id字段,而非全表,再進行join操作取出其他字段。
數據訪問開銷=索引IO+索引分頁后結果對應的表數據IO
優點:
每次翻頁消耗的資源和時間都基本相同,就像翻第一頁一樣
適用場景:
當查詢和排序字段(即where子句和order by子句涉及的字段)有對應覆蓋索引時,且中間結果集很大的情況時適用
- 批量SQL
減少和數據庫交互次數
- 對同一個表的多次alter操作必須合并為一次操作。
mysql對表的修改絕大部分操作都需要鎖表并重建表,而鎖表則會對線上業務造成影響。為減少這種影響,必須把對表的多次alter操作合并為一次操作。例如,要給表t增加一個字段b,同時給已有的字段aa建立索引, 通常的做法分為兩步:
然后增加索引:
alter table t add index idx_aa(aa);正確的做法是:
alter table t add column b varchar(10),add index idx_aa(aa);總結
數據庫是有狀態的服務,變更復雜而且速度慢,如果把業務邏輯放到數據庫中,將會限制業務的快速發展。建議把業務邏輯提前,放到前端或中間邏輯層,而把數據庫作為存儲層,實現邏輯與存儲的分離。
總結
以上是生活随笔為你收集整理的系统优化怎么做-SQL优化的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 系统优化怎么做-数据库优化
- 下一篇: 系统优化怎么做-Linux系统配置优化