查詢語句優化,從48秒到0 3秒

2021-08-26 15:40:21 字數 1280 閱讀 3183

**系統上線至今,資料量已經不知不覺上到500m,近8w記錄了。涉及資料庫操作的基本都是變得很慢了,用的人都會覺得躁火~~然後把這個情況在群裡一貼,包括機器配置什麼的一說,馬上就有群友發話了,而且幫我確定了不是機器配置的問題,「深圳-槍手」熱心人他的機器512記憶體過百w的資料裡也跑得飛快,甚至跟那些幾w塊的機器一樣牛(吹過頭了),呵呵~~~

在群友的分析指點下,嘗試把排序、條件等乙個乙個去除來做測試,結果發現問題就出在排序部分,去除排序的時候,執行時間由原來的48秒變成0.3x秒,這是個什麼檔次的變化呀~~看著這個結果我激動ing.....

於是我把涉及排序的字段組成乙個聯合索引alter table xx add index indexname(x1,x2,x3),經過2分鐘建立新索引之後再執行同乙個sql語句,哇塞0.28s。。。。爽

於是按照同樣的思路把其它幾個常用的sql作了過些優化,效果馬上見效

過了30分鐘再查slow sql記錄檔案,不好了,發現原來乙個好好的sql變得灰常慢了,神馬情況?

幾經分析和測試原來就是因為新增了聯合索引的原因,而且這個sql語句當中有個or,當把這個or改用union之後問題排除。

這回又得出乙個心得:寫sql的時候千萬別一時就手,隨便寫個就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一分析,發現在第一次分析過程中就返回了幾萬條資料:

where p.languages_id = 1 ,然後再依次根據條件,縮小範圍。

而我改變一下where 欄位的位置之後,速度就有了明顯地提高:

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條,接下來還要根據其它的條件來過濾,自然在速度上有了較大的提公升。

經過實踐發現,不要以為where中的字段順序無所謂,可以隨便放在哪,應該盡可能地第一次就過濾掉大部分無用的資料,只返回最小範圍的資料。

希望能幫到有同樣遭遇的朋友。

查詢語句優化,從48秒到0 3秒

系統上線至今,資料量已經不知不覺上到500m,近8w記錄了。涉及資料庫操作的基本都是變得很慢了,用的人都會覺得躁火 然後把這個情況在群裡一貼,包括機器配置什麼的一說,馬上就有群友發話了,而且幫我確定了不是機器配置的問題,深圳 槍手 熱心人他的機器512記憶體過百w的資料裡也跑得飛快,甚至跟那些幾w塊...

django後台載入從15秒優化到1秒的過程小記

之前django的後台管理的管理的專案很慢,開啟個頁面得花十幾秒甚至二十秒,經過不斷努力優化,終於優化到1秒左右了,很舒服。先定位慢的主要原因,首先有個表大概有200萬條資料,而且機器每天不停地寫入,增長很快。再利用diango debug 很方便檢視出哪些東西耗時,主要檢視各種耗時的sql語句。主...

SQL優化 秒級優化,hint讓IN子查詢當驅動表

python大資料與sql優化筆 qq群 771686295 在sql優化中,乙個比較重要的一點就是驅動表的選擇,hash join和nest loop來說驅動表的選擇是至關重要的。對於nest loop說最好是小表作為驅動表,與大表的連線鍵上減少索引,並且保證索引的選擇性比較好。對於hash jo...