SQL優化 索引優化

一、發現哪些sql語句有效能問題

開啟mysql慢查詢日誌對sql語句進行監控

show variables like

'slow_query_log'; -- 檢視是否開啟慢查詢日誌

set global slow_query_log = on; -- 開啟慢查詢日誌

set global log_queries_not_using_indexes = on;-- 記錄沒有使用索引查詢的sql語句

set global long_query_time=1;-- 將查詢時間大於1秒的語句記錄下來

show variables like

'slow%';--檢視慢查詢日誌所在的檔案位址

進行select語句查詢

開啟慢查詢日誌，檢視日誌資訊

c:\program files (x86)\mysql\mysql server 5.1\bin\mysqld, version: 5.1.73-community (mysql community server (gpl)). started with:

tcp port: 3306, named pipe: mysql

time                 id command    argument

# time: 170813 10:40:31

# user@host: root[root] @ localhost [127.0.0.1]

# query_time: 0.000000  lock_time: 0.000000 rows_sent: 373  rows_examined: 373

use eyesworld;

set timestamp

=1502592031;

select  * from city;

​

從第四行開始，日誌分為5個部分：

1.time：查詢語句執行開始時間

2.user@host：使用者名稱和ip

3.query_time 查詢所用時間 lock_time 鎖定時間 rows_sent 傳送的行數 rows_examined 掃瞄行數

4.timestamp：查詢語句執行時間的時間戳格式

5.查詢語句內容

慢查詢日誌分析工具：mysql dump slow和pt-query-digest

發現慢查詢日誌中有效能問題的sql：

1.查詢次數多，每次查詢占用時間長的sql（

pt-query-digest分析top前幾個的查詢語句）

2.io大的sql（rows examine掃瞄行數多的sql語句，掃瞄行數越多，io消耗越大）

3.未命名索引的sql（對比rows examined掃瞄行數 和 rows send實際傳送結果的行數，如果掃瞄行數遠遠大於傳送行數，則說明查詢的

命中率不高，效率低）

二、通過explain+sql語句查詢sql的執行計畫

例如：explain select id, province_name,city_name from city;

得到sql執行這個select語句的執行計畫：

select_type；select語句的型別，如果沒有where條件，則為******

table：表名

type：連線使用的型別：const、eq_reg、ref、range、index和all

possible_keys：可能使用的索引

key：

key_len：索引長度

ref：索引某一列被使用

rows：表掃瞄的行數（

可以通過建立索引來減少掃瞄行數）

extra：

三、count（）和max（）函式優化

max()函式：查詢大值，時間最後

select max(pay_date) from payment;-- 查詢最後一次的支付時間

執行max函式可能遇到的效能問題：

沒有加入索引，導致select語句對全表進行掃瞄

優化方法：

加入索引，減少表掃瞄的行數

create index idx_paydate on payment(payment_date);

count()函式優化：

count(*)優化成count(條件)

count(*)包含為null值的資料行

count(id or null)不包含為null值的資料行

四、子查詢優化

優化思路：把子查詢優化為join查詢

-- 子查詢

select * from table1 where table1.id

in (select table2.id
from table2);

​

-- 優化成join查詢

select * from table1 join table2 on table1.id = table2.id;

​

-- 去除重複資料（join查詢的結果可能出現重複）

select distince * from table1 join table2 on table1.id = table2.id;

五、group by查詢優化

六、limit優化（分頁功能）

limit 語句經常伴隨 order by 從句使用，經常需要排序（filesort），產生io問題

優化思想：避免過多的行掃瞄

-- 按照名字排序後取出第50--55行資料（全表掃瞄，檔案排序）

select id from table1 order

by name limit
50，5

​

-- 優化1：使用有索引的列或主鍵進行order by操作（使用主鍵排序，掃瞄55行）

select id from table1 order

by id limit
50，5  -- 用id索引做 order by 排序

​

-- 優化2：主鍵（id）過濾，先縮小id範圍，再進行order排序(只需掃瞄5行資料)

select id from table1 where id>50

and id<=60
order
by id limit
1,5

七、索引優化

優化思想：避免過多的行掃瞄

1.建立索引：where從句、group by、order by、on從句

2.索引字段越小越好（資料庫中儲存資料以頁為單位，欄位越小，每頁存的資料越多，io操作越少）

3.建立聯合索引（離散度大的放在前面，可選擇性越高）

-- 離散度大（重複值少）的字段放在前面

create index idx_union on

table(id_big, id_small);

​

select * from

table
where id_big = 200
and id_small = 10;

4.索引不是越多越好

建立索引可以提高查詢效率（select），但會降低寫入（update\insert\delete）效率。索引越多，執行時分析索引所用時間越多。

優化：找到冗餘索引，將其刪除

慢SQL優化 索引優化

在專案開發的時候難免會寫一些sql語句，剛開始資料量比較小或沒預料到資料的增長速度很快，在後期的維護中偶爾會有慢sql出現，嚴重的會影響到線上服務正常執行和使用者體驗。當然慢sql的優化角度有多種，比如增 減索引 調整搜尋條件的順序 優化查詢結果引數 分庫分表 讀寫分離等等，但本篇我們主要談一下索引...

sql索引優化

1 b tree索引 b tree索引的特點 以b 樹的結構儲存資料 能加快資料的查詢速度 更適合進行範圍查詢 什麼情況下可以用到b樹索引 1 全值匹配的查詢 eg sn 1111 1111 1111 1111 2 匹配最左字首的查詢 eg sn 1111 3 匹配範圍值的查詢 eg sn sn 4...

SQL優化 索引

索引說白了其實就是一種用於快速查詢資料的資料結構。像我在之前的工作裡mysql資料庫用的比較多一些，我了解的mysql底層索引使用的資料結構是b tree。你像b tree它其實就是在b tree的基礎上優化而來的，b tree和b tree最大的區別就是b tree不管是葉子節點還是非葉子節點除了...