每個數(shù)據(jù)庫平臺上的SQL開發(fā)人員都是在困難中求得生存，我們總是一次又一次犯同樣的錯誤，這是因為數(shù)據(jù)庫領(lǐng)域還相對不成熟，是的，每個數(shù)據(jù)庫廠商都在做著各種不同的努力，但作為開發(fā)人員仍然要克服各種問題，無論是在SQL Server，Oracle，DB2，Sybase，MySQL數(shù)據(jù)庫，還是其它關(guān)系數(shù)據(jù)庫平臺上編寫SQL代碼，并發(fā)性、資源管理、空間管理和SQL運(yùn)行速度總是困擾著開發(fā)人員。
遺憾的是，其中部分問題的解決沒有靈丹妙藥，也幾乎沒有最佳實踐。通常，開發(fā)人員有自己喜歡的SQL書寫習(xí)慣，一般不愿意去研究其它可行方案，當(dāng)然這可能是因為缺少培訓(xùn)的原因。我見得最多的就是在測試環(huán)境中SQL查詢運(yùn)行良好，但尚未在生產(chǎn)系統(tǒng)上進(jìn)行試運(yùn)行，就草草收場了，至于后來發(fā)現(xiàn)有問題，再被動式修改，因此最終用戶就痛苦了。
我不期望開發(fā)人員成為DBA，但我們編寫代碼時必須考慮生產(chǎn)時的問題，如果不在開發(fā)初期這么做，DBA發(fā)現(xiàn)后只能迫使我們返工。
我們通常說數(shù)據(jù)庫調(diào)試是一門技術(shù)，更是一門藝術(shù)，這是因為很少有現(xiàn)成的規(guī)則可以適應(yīng)一切問題的解決，你在一個系統(tǒng)上解決的問題在另一個系統(tǒng)上可能就不是問題了，反之亦然。涉及到查詢調(diào)整時，沒有一個答案是完全正確的，但這并不意味著你應(yīng)該放棄。
適當(dāng)遵循一些原則可以讓工作變得更加輕松，本文就列舉7個可以靈活運(yùn)用的原則，它們可以幫助你提高SQL查詢速度，當(dāng)然這些技巧你可以咨詢DBA獲得更多的信息。
1、用case代替
要更新一條記錄，我們立即會想到update，這個問題非常常見，許多開發(fā)人員經(jīng)常忽視這個原則，因為使用update看起來非常自然，非常合乎邏輯。
假設(shè)你從Customer表中提取記錄，你想將超過10萬美元的訂單標(biāo)記為“Preferred”，因此你會想到使用一條update語句將CustomerRank列更新為“Preferred”，問題是update語句是有日志的，這就意味著每條記錄它會寫兩次，解決這個問題的辦法就是在SQL查詢中內(nèi)嵌case語句，在向表寫入“Preferred”標(biāo)志前，它會用訂單金額條件對每一行進(jìn)行檢查，滿足條件的才會更新，性能的提升是驚人的。
2、不要盲目地重用代碼
這個問題也非常常見，在工作中直接用別人寫好的代碼是一件痛快的事情，你知道這些代碼可以查詢出你需要的數(shù)據(jù)，但問題是往往有些數(shù)據(jù)不是你需要的，但我們常常不愿意做一下修改，因此返回的數(shù)據(jù)集往往是一個超集，很可能多用一個外連接或是一個where子句就可以解決問題，因此在復(fù)用代碼時最好檢查一下，如有必要略做適應(yīng)性修改。
3、只提取你需要的列
這個問題和2有點類似，但這次是指定具體的列。也許我們在使用select * 時感覺很暢快，多省事呀!如果要將每個列名都寫出來，太麻煩了，這是很多人的想法，但這種想法是錯誤的，因為這樣做會取出多余的數(shù)據(jù)列，我無數(shù)次看到犯這種錯誤的代碼，曾經(jīng)有一位開發(fā)人員對一張有120列，上百萬行數(shù)據(jù)的表使用select * 查詢，但他只會用到其中的三五列，這是對資源的極大浪費，我們建議拒絕書寫select * ，你要什么就查詢什么，多余的返回結(jié)果對你沒用，雖然不影響你要實現(xiàn)的功能，但對數(shù)據(jù)庫性能卻有極大的影響。
4、盡可能只查詢一次大表
這也是我看到很多人犯的錯誤，例如，某存儲過程從一張上百萬條記錄的大表中取數(shù)據(jù)，開發(fā)人員想提取居住在加利福利亞且收入高于4萬美元的客戶信息，因此它先將居住在加利福利亞的客戶取出放在一張臨時表中，然后再查詢收入高于4萬美元的客戶，將查詢結(jié)果放入另一張臨時表中，最后，他連接這兩張臨時表查詢出最終的結(jié)果。
可能有人認(rèn)為我是在開玩笑吧?但事實是確實有人這么做，這應(yīng)該在一個查詢中就能完成，卻查詢了兩次大表。
有種稍微不同的情況是，當(dāng)一個過程中的多個步驟需要大表的子集時，每一步可能都必須查詢一次大表。避免多次查詢的辦法是持久化第一次查詢的子集，然后將后面的步驟指向該持久化子集。
5、使用臨時表
這個問題解決起來可能稍微有點麻煩，但其效果比較明顯，其實在很多時候你都可以使用臨時表，通過臨時表可以有效地減少對大表的操作，如果你必須連接一個表到大表，并且在大表上有條件，這時就可以將大表中需要的數(shù)據(jù)輸出到臨時表中，然后再用該臨時表進(jìn)行連接，這樣查詢速度會有明顯改進(jìn)。如果你的存儲過程中有多個查詢需要需要連接到相同的表時，也可以使用臨時表。
6、預(yù)存數(shù)據(jù)
這一條是我最喜歡的，因為它是一項很老的技術(shù)，常常被人們忽視，如果你有一個報表或存儲過程需要連接大表，提前提取大表中的數(shù)據(jù)，持久化存儲到另一張表中，報表就可以使用預(yù)存的數(shù)據(jù)集，從而提高整體執(zhí)行效率。
并不是所有時候你都有機(jī)會利用該技術(shù)，但一旦能利用上，你會發(fā)現(xiàn)它是節(jié)省服務(wù)器資源很有效的辦法。
但遺憾的是，很多開發(fā)人員都在盡力回避這種技術(shù)，實際上只需要創(chuàng)建一個視圖就可以把問題解決了，但這種方法的問題是每個需要它的報表運(yùn)行時都會執(zhí)行一次，但對于同一個報表，假設(shè)10分鐘前運(yùn)行了一次，現(xiàn)在有人要再運(yùn)行該報表，那么對大表的連接操作就可以避免掉了。我建議對那些經(jīng)常被查詢的表使用該技術(shù)將數(shù)據(jù)預(yù)存起來，可以節(jié)省大量的服務(wù)器資源。
7、分批刪除和更新
這也是一個容易被忽視的技巧，對一個大表做數(shù)據(jù)刪除或更新操作，如果操作不當(dāng)可能是一場噩夢，問題是這兩種操作都是單一的事務(wù)，如果你需要殺死它們，或它們在執(zhí)行時系統(tǒng)遇到問題，必須全部回滾整個事務(wù)，這個時間可能非常長，這就是為什么我們在刪除數(shù)十萬條記錄時，如果試圖中途殺死進(jìn)程幾乎沒用的原因，這些操作也會影響到其它事務(wù)，搞不好會造成死循環(huán)，因此應(yīng)慎用。
解決這個問題的辦法就是分批少量刪除或更新，首先，無論什么原因需要結(jié)束事務(wù)，只需要回滾少量的行，此外，小批量提交數(shù)據(jù)寫入磁盤，對I/O的要求也更低，并發(fā)性可以大大提高。
另外要提醒的是，執(zhí)行刪除和更新操作應(yīng)盡量選擇非高峰時段。
總結(jié)
遵循這些方法總是能收到效果，但在實踐中，應(yīng)該評估選用一種或幾種最佳方案，大家一定要記住，沒有那種辦法是萬能的。另外，這些技巧適用于所有數(shù)據(jù)庫品種，因此你必須全部掌握。
