表結構如下：
主要用到fis_backup、fid和fstatus幾個欄位做查詢。
索引如下：
整張表，前半部分資料fis_backup都是1，後半部分資料fis_backup都是0，共2000w多條資料
查詢語句如下：
select *
from `t_mp_comment` c
where c.fid>=15041538 and c.fstatus!=9 and c.fis_backup=0
order by c.fid
limit 100;
select
count(1) from
`t_mp_comment` a where a.`fis_backup`=1; //資料有1000w
select
count(1) from
`t_mp_comment` a where a.`fis_backup`=0; //資料也有1000w
select *
from
`t_mp_comment` c
where c.fid>=15041538
and c.fstatus!=9
and c.fis_backup=0
order
by c.fid
limit 100;
id select_type table type possible_keys key key_len ref rows extra
1 ****** c ref primary,idx_fisbackup idx_fisbackup 1
const
11799193 using where
select *
from
`t_mp_comment` c
where c.fid>=15041538
and c.fstatus!=9
and c.fis_backup=1
order
by c.fid
limit 100;
id select_type table type possible_keys key key_len ref rows extra
1 ****** c ref primary,idx_fisbackup idx_fisbackup 1
const
11799193 using where
第二種情況：
語句1耗時0.002秒，語句如下：
select *
from
`t_mp_comment` c
where c.fid>=0
and c.fstatus!=9
and c.fis_backup=1
order
by c.fid
limit 100;
id select_type table type possible_keys key key_len ref rows extra
1 ****** c ref primary,idx_fisbackup idx_fisbackup 1
const
11799193 using where
select *
from
`t_mp_comment` c
where c.fid>=0
and c.fstatus!=9
and c.fis_backup=0
order
by c.fid
limit 100;
id select_type table type possible_keys key key_len ref rows extra
1 ****** c ref primary,idx_fisbackup idx_fisbackup 1
const
11799193 using where
所以，若執行計畫中有where，一定要小心全表掃瞄！
一次mysql優化經歷
某日運維突然說無線終端的頻道頁介面訪問量很大，memcache快取扛不過來，導致mysql併發查詢量太大，導致伺服器不停地宕機，只能不停地重啟機器。遺憾的是運維並沒有告訴mysql查詢量具體有多大 無量化，比如一秒多少個查詢 針對這個問題，有同事建議改了mysql memcache的架構，採用red...
一次優化經歷
問題 excel資料匯入，儲存到資料庫中，為了優化查詢效率和其他一些業務需求，需要將資料的一列屬性切分後儲存到redis中，插入資料庫前要保證其中乙個屬性不重複，另外乙個屬性已經在資料庫中。為了將問題描述簡單些，我們假設excel中有兩列資料a和b，其中資料a要保證資料庫中不重複，資料b保證資料庫中...
一次mysql優化經歷
某日運維突然說無線終端的頻道頁介面訪問量非常大，memcache快取扛只是來。導致mysql併發查詢量太大，導致server不停地宕機，僅僅能不停地重新啟動機器。遺憾的是運維並沒有告訴mysql查詢量詳細有多大 無量化，比方一秒多少個查詢 針對這個問題。有同事建議改了mysql memcache的架...