資料庫優化 SQL優化

前面一篇文章從例項的角度進行資料庫優化，通過配置一些引數讓資料庫效能達到最優。但是一些「不好」的sql也會導致資料庫查詢變慢，影響業務流程。本文從sql角度進行資料庫優化，提公升sql執行效率。

判斷sql是否有問題時可以通過兩個表象進行判斷：

可以使用sar命令，top命令檢視當前系統狀態。

也可以通過prometheus、grafana等監控工具觀察系統狀態。（感興趣的可以翻看我之前的文章）

冗長的sql都好理解，一段sql太長閱讀性肯定會差，而且出現問題的頻率肯定會更高。更進一步判斷sql問題就得從執行計畫入手，如下所示：

執行計畫告訴我們本次查詢走了全表掃瞄type=all，rows很大(9950400)基本可以判斷這是一段"有味道"的sql。

不同資料庫有不同的獲取方法，以下為目前主流資料庫的慢查詢sql獲取工具

oracle

達夢資料庫

sql編寫有以下幾個通用的技巧：

• 合理使用索引

索引少了查詢慢；索引多了占用空間大，執行增刪改語句的時候需要動態維護索引，影響效能

選擇率高（重複值少）且被where頻繁引用需要建立b樹索引；一般join列需要建立索引；複雜文件型別查詢採用全文索引效率更好；索引的建立要在查詢和dml效能之間取得平衡；復合索引建立時要注意基於非前導列查詢的情況

union all的執行效率比union高，union執行時需要排重；union需要對資料進行排序

執行sql時優化器需要將 * 轉成具體的列；每次查詢都要回表，不能走覆蓋索引。

一般join欄位都提前加上索引

提公升可閱讀性；避免慢查詢的概率；可以轉換成多個短查詢，用業務端處理

• 避免order by rand()類似寫法

rand()導致資料列被多次掃瞄

字段解釋

id每個被獨立執行的操作標識，標識物件被操作的順序，id值越大，先被執行，如果相同，執行順序從上到下

select_type

查詢中每個select 字句的型別

table

被操作的物件名稱，通常是表名，但有其他格式

partitions

匹配的分割槽資訊(對於非分割槽表值為null)

type

連線操作的型別

possible_keys

可能用到的索引

key優化器實際使用的索引(最重要的列) 從最好到最差的連線型別為const、eq_reg、ref、range、index和all。當出現all時表示當前sql出現了「壞味道」

key_len

被優化器選定的索引鍵長度，單位是位元組

ref表示本行被操作物件的參照物件，無參照物件為null

rows

查詢執行所掃瞄的元組個數（對於innodb，此值為估計值）

filtered

條件表上資料被過濾的元組個數百分比

extra

執行計畫的重要補充資訊，當此列出現using filesort,using temporary字樣時就要小心了，很可能sql語句需要優化

接下來我們用一段實際優化案例來說明sql優化的過程及優化技巧。

sql優化,資料庫優化

1.sql的執行順序 from 表名 where 條件 執行順序是從後往前，where條件後面的語句盡可能縮短where 資料執行的範圍。先group by 後order by select 查詢 2.避免過多的聯查，設計合理的表關係 3.遵守常見sql規範，盡可能減少 4.如果表字段過多，經常展示...

sql優化 資料庫優化

資料庫優化 資料庫優化吧我覺應該從硬碟 記憶體和網路頻寬考慮，提高硬碟的讀寫速度，增大頻寬提高吞吐量，增大伺服器記憶體，可以採用讀寫分離，降低單台資料庫的訪問壓力，查詢的時候控制資料量的大小，返回更少資料，減少互動次數，減少cpu及記憶體的開銷，sql優化 如果乙個表中資料量過大我們可以採用橫切割，...

資料庫優化 sql語句優化

1 group by語句優化 因為mysql對所有group by的字段進行排序，所以如果包含group by但是想要避免排序結果的消耗，可以指定order by null來進行group by的排序。select id,sun moneys from sales group by id expla...