昨天聽(tīng)開(kāi)發(fā)人員提到,相關(guān)的彩票網(wǎng)頁(yè)當(dāng)中一個(gè)頁(yè)面刷新的很慢,特別是在提取數(shù)據(jù)的時(shí)候, 今天早上一到,便去找開(kāi)發(fā)人員要去相關(guān)的也沒(méi)進(jìn)行瀏覽,窺探哪些數(shù)據(jù)出現(xiàn)了問(wèn)題,開(kāi)發(fā)人員 使用PHP開(kāi)發(fā),所以我用IE很容易就可以窺探到哪些sql執(zhí)行的很慢,比如下; www. ![]() 這個(gè)圖上列出了,也沒(méi)中取sql語(yǔ)句的相關(guān)執(zhí)行時(shí)間預(yù)估比例,以此我可以探查到大概哪些語(yǔ)句會(huì) 影響到我們的業(yè)務(wù)系統(tǒng)!首先看到了有個(gè)500,200毫秒的問(wèn)題,熟話說(shuō),槍打出頭鳥(niǎo),哈哈,優(yōu)化 也一樣,先把大的問(wèn)題解決了,在來(lái)收拾小的問(wèn)題(小的問(wèn)題,也有可能受到大問(wèn)題的干預(yù)造成), 于是我便把該語(yǔ)句找出來(lái);如下; SELECT a.user_name as username, a.order_date as ordertime, a.bonus_value as bonus, cm.name_1 as lname FROM lot_sellform AS a INNER JOIN code_mst AS cm ON a.lottery_id = cm.cd AND a.lottery_type = cm.lot_type WHERE a.bonus_value > 0 ORDER BY a.order_date DESC limit 10 www. 基本上改弄的索引信息都弄到了,但是我在頁(yè)面中卻看到了這樣的情況;如圖; ![]() 看到type類(lèi)型基本都走了索引,而且extra列內(nèi)還有using temporary,using filesort,他們用到了 臨時(shí)表和在文件內(nèi)進(jìn)行了排序,才返回出來(lái),這肯定不是按照我們?cè)仍O(shè)計(jì)的最優(yōu)路線來(lái)走的, 而且相關(guān)的索引路線都沒(méi)走上,這里我有查了相關(guān)的資料,在官網(wǎng)上,看到如下內(nèi)容;(我用藍(lán)色 來(lái)表名相關(guān)的信息) 在某些情況中,MySQL可以使用一個(gè)索引來(lái)滿足ORDER BY子句,而不需要額外的排序。 www. 即使ORDER BY不確切匹配索引,只要WHERE子句中的所有未使用的索引部分和所有額外的 ORDER BY 列為常數(shù),就可以使用索引。下面的查詢使用索引來(lái)解決ORDER BY部分: SELECT * FROM t1 ORDER BY key_part1,key_part2,... ; SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2; SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC; SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC; 這幾句話嚴(yán)重勾起了我的興趣,愛(ài)好!哈,在排序中,去查看沒(méi)有進(jìn)行索引,而且我在日期列上 添加了btree索引了!怎么會(huì)沒(méi)走呢?以下是圖信息; www. ![]() 從上圖可以看出,排序仍然是在臨時(shí)表,和文件中進(jìn)行了,而且type還是ALL比較耗時(shí)的操作, 這里我又會(huì)想起前面官網(wǎng)中提及到的,key_part1,key_part2這兩列,在where語(yǔ)句中,和order by中 出現(xiàn)的比率這么頻繁,而且上面說(shuō),如果where語(yǔ)句中只要為啥用索引語(yǔ)句列的部分,和所有order by 列的數(shù)據(jù)如果為常數(shù),可以使用索引路線來(lái)走,那如果我對(duì)兩者來(lái)進(jìn)行彼此的綁定了,比如;讓其 來(lái)做個(gè)組合索引! www. 首先where條件中bonus_value的值,我們?nèi)〉檬浅?shù),而且在進(jìn)行排序的時(shí)候,我們選擇的是 order_date日期的列值,如果彼此來(lái)進(jìn)行綁定組合,sql在選擇路線的窺探中首先會(huì)嘗試,組合索 引中位于第一列的數(shù)列,進(jìn)行handle的鎖定,遍歷到數(shù)值后會(huì)繼續(xù)留住該handle的位于LRU列表 頭中,接著繼續(xù)進(jìn)行數(shù)值的排序遍歷結(jié)果集合,直到handle列被擠出index維護(hù)的元頭之外! 其實(shí)這個(gè)不是讓其走我們的bonus_value,order_date索引路徑,而且讓其走到我們前面INNER JOIN 中的索引路線,避免了讓數(shù)據(jù)在臨時(shí)表中出現(xiàn),或者在磁盤(pán)文件中排序,其實(shí)就是增大了,我們?cè)阪溄?br>條件中我們?cè)O(shè)計(jì)索引路線的概率問(wèn)題!有點(diǎn)聲東擊西的概念!哈!以下圖供參考: ![]() 以此看到走了我們需要的索引路徑了! |
|
來(lái)自: CevenCheng > 《查詢優(yōu)化》