MySQL的SQL優化

此查詢需要一個小時MySQL的SQL優化

select *, 
     unix_timestamp(finishtime)-unix_timestamp(submittime) timetaken 
from joblog 
where jobname like '%cas%' 
and submittime>='2013-01-01 00:00:00' 
and submittime<='2013-01-10 00:00:00' 
order by id desc limit 300;

，但相同的查詢與一個submittime完成像0.03秒

表中有2.1萬行

任何想法什麼導致問題或如何調試

來源

2013-01-17 Jabir Ahmed

請在發佈前正確地格式化你的代碼。http://sqlformat.appspot.com/是SQL的好工具。 –

從[B -Tree Index Characteristics]（http://dev.mysql.com/doc/en/index-btree-hash.html）：「*如果'LIKE'的參數是'LIKE'，那麼索引也可以用於'LIKE'比較***「（我的強調） – eggyal

你是什麼意思*一個submittime *查詢速度快嗎？你的意思是如果你運行'submittime> x'而不是'submittime在x和y'之間？ –

您的第一步應該是使用MySQL EXPLAIN來查看查詢的內容。它可能會給你一些關於如何解決你的問題的見解。

我的猜測是jobname LIKE '%cas%'是最慢的部分，因爲您正在進行通配符文本搜索。在這裏添加索引不會有幫助，因爲你有一個領先的通配符。有沒有辦法做這個查詢沒有像這樣的前導通配符？同時在submittime上添加索引可能會提高此查詢的速度。

來源

2013-01-17 17:15:02 Oleksi

是的，我嘗試沒有'％cas％，它工作正常。但與CAS添加了23秒的延遲 –

有沒有差異有或沒有CAS在輸出說明http://pastebin.com/MG1D4uSB –

我不知道，但你應該發佈EXPLAIN輸出在你的問題中別人看到。 – Oleksi

您可以嘗試添加了限制查詢，看看是否能增加它返回的速度...從http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

摘錄

「有時MySQL不使用索引，即使一個是有一種情況是，優化器估計使用索引需要MySQL訪問表中很大一部分的行（在這種情況下，表掃描可能會更快，因爲它需要）但是，如果這樣的查詢使用LIMIT只檢索一些行，MySQL無論如何都會使用索引，因爲它可以更迅速地找到res中返回的少數幾行ULT。「

來源

2013-01-17 17:20:39 Dan

我在這裏使用了300的限制，但仍然很慢 –

select *,unix_timestamp(finishtime)-unix_timestamp(submittime) timetaken 
from joblog 
where (submittime between '2013-01-10 00:00:00' and '2013-01-19 00:00:00') 
and jobname is not null 
and jobname like '%cas%';

這有助於

（0.93秒），

來源

2013-01-18 07:04:08

回答

相關問題