[SQL ] 為什麼select這麼慢?

看板Database (資料庫)作者ppanerai (全職業封頂路途漫長)時間18年前 (2006/07/05 10:35)推噓7(7推 0噓 0→)

留言7則, 5人參與討論串1/1

常常會聽到有這種說法: "select動作很慢是不是 Hardware/OS/database config 有問題" 大致上歸類有以下幾種情形 (這是我自己的分類~~呵~~) 1.應用程式這邊我指的是 - 設計與實作這個部分也是最容易看到效果也最不花錢的但是最花時間 @@ 設計通常是比較難解決的如 table design 的錯誤想改正可能要整個打掉重做若是開發中或是測試用的系統可能還好但是...prod DB怎麼可以說停就停說打就打有些機器整年都不能停...那怎麼辦? @@" 實作這一段就是重點了我所經驗過的效率問題(雖然不是很多經驗) 80%以上集中在這一塊一般程式師由於對資料庫的"操作"不熟悉因此好像總有個印象認為只要懂得 SELECT、JOIN、Group 就好也就是只求正確(嗯...Schedule的壓力問題我們不討論 = =) 我所說的操作並不是單純下下SQL就OK 而是一些基本可以避開的問題點算是基礎觀念在這一方面如果可以做到盡可能避免這些問題不只可做出效率佳的程式也可減少在硬體上的成本浪費以下與資料庫本身的廠家設計無關我想應該通用吧 ^^ 大部分我還是以 Oracle 為主 A).存取Data的數量不必要的data勿 select 出來後再剔掉盡量在SQL上將存取的限制做好程式可以少處理一筆就少處理 B).Index的使用適當使用Indexes 在random access時可以確保程式的效率但也需要避免Indexes的濫用如一個table有 10以上的 indexes 不要懷疑就是會有 = =" 我想各個資料庫的Index基本原理是大同小異的但可以提供的功能確可能不太相同如: 欄位是否可以倒置存取資料超過整個table多少%時 Index反而浪費Resource 這些需要查過手冊才知道 C).網路傳輸這是最容易被忽略的一個部分常常程式師會將Business寫在前端(指非資料庫)的程式中因此將data透過網路由Client(包括Applicatin Server)處理在網路傳輸上面浪費時間是一件可怕的事我們很可能無法察覺原來程式的效率瓶頸出在這裡我曾試過將整個 program 寫在 Store Procedure/Function中與寫在前端的應用程式中使用相同的 SQL , Data數量 , database config 速度可以相差到 10倍 = =" D).批次工作的分配有資料產生就一定有報表需求報表通常是User最會Complain的一個部分我們可以將這些批次工做分配到時間軸上而不是一次跑完舉例說明若系統每月需產生月報表則每日將當日結算資料設計產生至另一個日結算table 跑月報表時將可以大大節省時間當然有些情況下無法設計日結算的table(可能因BUSINESS問題) 這就需要靠各位的 Know How 及智慧去解決嚕 E).轉個彎會不會更好有些時候無法避免需要存取的 data就是這麼多上面提到的幾點也都考慮了但還是跑很久由於data原本就需處理這麼多這時是不是用些偷吃步的做法(呵~) 可能會讓程式跑的更快舉例將需存取的資料先暫存於某一temp table 再進行處理這一部分的應用需要對資料庫本身的Feature有一定的瞭解否則反而會造成其他資料庫的影響 2.系統異常嘿...這個呢有可能發生在任何一個環節 OS NETWORK DATABASE 都有可能不過異常通常會導致...完全沒辦法動 = =" 如 Oracle 8i 中 temporary segment會發生的錯誤 storage parameter setting 所以也跳過 (我看是不知從何講起吧噗~) 3.Hardware/OS/database - Config 有問題這個我們不討論 (是因為不知道怎麼討論吧 @O@ ) 因為發生的機會實在...不高 config 有問題機器開始跑的第一天就會知道了不會等到跑了好一陣子才出現 = = ===================================================== 如果以上的問題都已經處理過了還是不滿意那就...花錢買硬體吧不過擴充硬體實在是個無底洞 @@" 而且效果有限得很... 還有一點很重要如果說... 你的資料庫TABLE永遠也不會超過某一個數量(如 100,000 筆) 那...上面有些情況就可以不用考慮了反正 ... 多做了些工也感覺不出來快在哪裡 QQ 最後要提到 Performance Tuning 永遠都是很花時間的需要實際資料量的執行以得到真正的tuning效果評估永遠是評估實作完測試後才知道 - 改變後的做法及測試的問題點究竟是不是問題所在以上如有謬誤還請各位指點 ^^ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 202.145.230.2