昨天聽開發人員提到，相關的彩票網頁當中一個頁面刷新的很慢，特別是在提取數據的時候，
今天早上一到，便去找開發人員要去相關的也沒進行浏覽，窺探哪些數據出現了問題，開發人員
使用PHP開發，所以我用IE很容易就可以窺探到哪些sql執行的很慢，比如下；
www.2cto.com
這個圖上列出了，也沒中取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
www.2cto.com
基本上改弄的索引信息都弄到了，但是我在頁面中卻看到了這樣的情況；如圖；
看到type類型基本都走了索引，而且extra列內還有using temporary，using filesort，他們用到了
臨時表和在文件內進行了排序，才返回出來，這肯定不是按照我們原先設計的最優路線來走的，
而且相關的索引路線都沒走上，這裡我有查了相關的資料，在官網上，看到如下內容；（我用藍色
來表名相關的信息）
在某些情況中，MySQL可以使用一個索引來滿足ORDER BY子句，而不需要額外的排序。
www.2cto.com
即使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索引了！怎麼會沒走呢？以下是圖信息；
www.2cto.com
從上圖可以看出，排序仍然是在臨時表，和文件中進行了，而且type還是ALL比較耗時的操作，
這裡我又會想起前面官網中提及到的，key_part1,key_part2這兩列，在where語句中，和order by中
出現的比率這麼頻繁，而且上面說，如果where語句中只要為啥用索引語句列的部分，和所有order by
列的數據如果為常數，可以使用索引路線來走，那如果我對兩者來進行彼此的綁定了，比如；讓其
來做個組合索引！
www.2cto.com
首先where條件中bonus_value的值，我們取得是常數，而且在進行排序的時候，我們選擇的是
order_date日期的列值，如果彼此來進行綁定組合，sql在選擇路線的窺探中首先會嘗試，組合索
引中位於第一列的數列，進行handle的鎖定，遍歷到數值後會繼續留住該handle的位於LRU列表
頭中，接著繼續進行數值的排序遍歷結果集合，直到handle列被擠出index維護的元頭之外！
其實這個不是讓其走我們的bonus_value，order_date索引路徑，而且讓其走到我們前面INNER JOIN
中的索引路線，避免了讓數據在臨時表中出現，或者在磁盤文件中排序，其實就是增大了，我們在鏈接
條件中我們設計索引路線的概率問題！有點聲東擊西的概念！哈！以下圖供參考：
以此看到走了我們需要的索引路徑了！
