昨天聽(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í)行的很慢，比如下；

這個(gè)圖上列出了，也沒(méi)中取sql語(yǔ)句的相關(guān)執(zhí)行時(shí)間預(yù)估比例，以此我可以探查到大概哪些語(yǔ)句會(huì)
影響到我們的業(yè)務(wù)系統(tǒng)！首先看到了有個(gè)500,200毫秒的問(wèn)題，熟話(huà)說(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

基本上改弄的索引信息都弄到了，但是我在頁(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)滿(mǎn)足ORDER BY子句，而不需要額外的排序。

即使ORDER BY不確切匹配索引，只要WHERE子句中的所有未使用的索引部分和所有額外的
ORDER BY 列為常數(shù)，就可以使用索引。下面的查詢(xún)使用索引來(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;

這幾句話(huà)嚴(yán)重勾起了我的興趣，愛(ài)好！哈，在排序中，去查看沒(méi)有進(jìn)行索引，而且我在日期列上
添加了btree索引了！怎么會(huì)沒(méi)走呢？以下是圖信息；

從上圖可以看出，排序仍然是在臨時(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è)組合索引！

首先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)聲東擊西的概念！哈！以下圖供參考：

以此看到走了我們需要的索引路徑了！

聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com