【it168 技術】觸及資料庫操作的基本都是變得很慢了，用的人都會覺得躁火~~然後把這個情況在群裡一貼，包括機器配置什麼的1說，馬上jiuyouqunyou發話了，而且幫我確定了不是機器配置的問題，「深圳-槍手」熱心人他的機器512記憶體過百w的資料裡也跑患上飛快，甚至跟那些幾w塊的機器一樣牛(吹過頭了)，呵呵~~~
在群友的分析指點xia，嘗試把排序、條件等乙個乙個去除來做測試，結果發現問題就出在排序部分，去除排序的時候，執行時間由原來的48秒變成0.3x秒，這是個什麼檔次的bianhua呀~~看著這個結果我激動ing.....
於是我把涉及排序的字段組成乙個聯合索引alter table xx add index indexname(x1,x2,x3)，經由2分鐘創立新索引zhihou再執行同乙個sql語句，哇塞0.28s。。。。爽
於是依照一樣的思路把其它幾個常用的sql作了過些優化，效果馬上見效
過了30分鐘再查slow sql記錄檔案，不好了，發現原來乙個好好的sql變得灰常慢了，神馬情況?
幾經分析和測試原來就是因為新增了聯合索引的原因，而且這個sql語句當中有個or，當把這個or改用unionzhihou問題排除。
這回又得出乙個心得：xiesql的時候千萬別一時就手，隨便寫個就ok，那會為以為帶來很嚴重的後果。
在用mysql查詢資料庫的時候，連線了良多個用，發現無比慢。例如：
select ... where p.languages_id = 1 and m.languages_id =
1 and c.languages_id = 1 and t.languages_id =
1 and p.products_id in (472,474)
這樣查詢需要20多秒，雖然在各個欄位上都建立了索引。用分析explain sql一分析，發現在第一次分析guocheng中就返回了幾萬條資料：
where p.languages_id = 1 ，然後再依次依據前提，縮小範圍。
而我改變一下where 欄位de位置之後，速度就有了顯明地提高：
where p.products_id in (472,474) and
p.languages_id = 1 and m.languages_id = 1 and c.languages_id =
1 and t.languages_id = 1
這樣，第一次的條件是p.products_id in (472,474)，它返回的結果只有不到10條，接下來還要根據其它的前提來過濾，自然在速度上有了較大的tisheng。
經過實踐發現，不要以為where中的字段順序無所謂，可以隨便放在哪，應當盡量地第一次就過濾掉大部分無用的資料，只返回最小範圍的資料。
希望能幫到有同樣遭遇的朋友。
SQL查詢優化,注意where條件的順序
1.測試表 employee 雇員id 部門id 薪金 emp id dept id salary 01 01 1050 02 01 2000 ok,我們要查詢部門01下,薪金高於1000的雇員 2.原則及兩個sql的對比 原則,多數資料庫都是從 左到右的順序處理條件,把能過濾更多資料的條件放在前面...
SQL查詢優化,注意where條件的順序
sql查詢優化,注意where條件的順序 1.測試表 employee 雇員id 部門id 薪金 emp id dept id salary 01 01 1050 02 01 2000 ok,我們要查詢部門01下,薪金高於1000的雇員 2.原則及兩個sql的對比 原則,多數資料庫都是從 左到右的順...
SQL查詢的where條件優化之一
對於mssql中，查詢是非常普遍的事情。對於where後面的條件。系統預設是從左右依次執行的。所以介於此，我們需要把能夠大範圍過濾掉資料的條件優先排在前面。同理逐級遞減。舉個簡單的例子。有個表 students 資料有100000條 select id,name,age from students ...