記一次MySQL索引優化

兩張表是主（check_drawings）從（check_drawings_img）關係。

check_drawings，主表資料 3591條。

select

count(*) from check_drawings; -- 3591

select count(*) from check_drawings_img; -- 107203

select

cdi.*,
cd.booth_id 
from
check_drawings_img cdi,
check_drawings cd 
where cdi.check_drawings_id =
cd.id 
and cd.exhibition_id =
'c480ffc7aed24789b025397c5b66ce88
'and cdi.upload_time =
(select
max(cdi2.upload_time) 
from
check_drawings_img cdi2 
where cdi2.check_drawings_id = cd.id) ;

select識別符，這是select查詢序列號。

select_type

****** 它表示簡單的select,沒有union和子查詢

primary 最外面的select,在有子查詢的語句中，最外面的select查詢就是primary

dependent_subquery 看到 sql 執行計畫中 select_type 字段**現「dependent subquery」時，需要特別注意了。

type

all : 即全表掃瞄

index : 按索引次序掃瞄，先讀索引，再讀實際的行，結果還是全表掃瞄，主要優點是避免了排序。因為索引是排好的。

range:以範圍的形式掃瞄。

ref:非唯一索引訪問(只有普通索引)

eq_ref:使用唯一索引查詢(主鍵或唯一索引)

const:常量查詢

解決方式一增加索引：

1、增加索引，我們對外檢check_drawings_img.check_drawings_id增加索引如下：

alter

table check_drawings_img add
index check_drawings_id_idx (check_drawings_id) ;

看下執行計畫：

mysql 記一次優化多個索引的過程

一 資料庫中的鋪地資料100w，二 使用到的where條件 三 優化歷程 索引的選擇，因為含有order by，所以後面的字段必須要加到索引裡面，查詢效果 第一種方式，alter table table name add index slp t ttkd order index9 zex id,or...

記一次SQL優化

問題發生在關聯主表a 4w資料量 和副表b 4w資料量 關聯欄位都是openid 當時用的是 left join 直接跑sql，卡死 伺服器也是差 優化1 改left join 為join，兩者區別就是left join查詢時已主表為依據，該是幾條就幾條 就算副表沒有關聯的資料 join如果副表沒有...

記一次 MySQL 的慢查優化

最近遇見乙個 mysql 的慢查問題，於是排查了下，這裡把相關的過程做個總結。我首先檢視了 mysql 的慢查詢日誌，發現有這樣一條 query 耗時非常長 大概在 1 秒多 而且掃瞄的行數很大 10 多萬條資料，差不多是全表了 select from tgdemand demand t1 wher...