昨天聽開發人員提到，相關的彩票網頁當中一個頁面刷新的很慢，特別是在提取數據的時候，
今天早上一到，便去找開發人員要去相關的也沒進行瀏覽，窺探哪些數據出現了問題，開發人員
使用PHP開發，所以我用IE很容易就可以窺探到哪些sql執行的很慢，比如下；

這個圖上列出了，也沒中取sql語句的相關執行時間預估比例，以此我可以探查到大概哪些語句會
影響到我們的業務系統！首先看到了有個500,200毫秒的問題，熟話說，槍打出頭鳥，哈哈，優化
也一樣，先把大的問題解決了，在來收拾小的問題（小的問題，也有可能受到大問題的干預造成），
于是我便把該語句找出來；如下；

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

基本上改弄的索引信息都弄到了，但是我在頁面中卻看到了這樣的情況；如圖；

看到type類型基本都走了索引，而且extra列內還有using temporary，using filesort，他們用到了
臨時表和在文件內進行了排序，才返回出來，這肯定不是按照我們原先設計的最優路線來走的，
而且相關的索引路線都沒走上，這里我有查了相關的資料，在官網上，看到如下內容；（我用藍色
來表名相關的信息）

在某些情況中，MySQL可以使用一個索引來滿足ORDER BY子句，而不需要額外的排序。

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

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

從上圖可以看出，排序仍然是在臨時表，和文件中進行了，而且type還是ALL比較耗時的操作，
這里我又會想起前面官網中提及到的，key_part1,key_part2這兩列，在where語句中，和order by中
出現的比率這么頻繁，而且上面說，如果where語句中只要為啥用索引語句列的部分，和所有order by
列的數據如果為常數，可以使用索引路線來走，那如果我對兩者來進行彼此的綁定了，比如；讓其
來做個組合索引！

首先where條件中bonus_value的值，我們取得是常數，而且在進行排序的時候，我們選擇的是
order_date日期的列值，如果彼此來進行綁定組合，sql在選擇路線的窺探中首先會嘗試，組合索
引中位于第一列的數列，進行handle的鎖定，遍歷到數值后會繼續留住該handle的位于LRU列表
頭中，接著繼續進行數值的排序遍歷結果集合，直到handle列被擠出index維護的元頭之外！

其實這個不是讓其走我們的bonus_value，order_date索引路徑，而且讓其走到我們前面INNER JOIN
中的索引路線，避免了讓數據在臨時表中出現，或者在磁盤文件中排序，其實就是增大了，我們在鏈接
條件中我們設計索引路線的概率問題！有點聲東擊西的概念！哈！以下圖供參考：

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

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com