一句SQL語句，可能就是一個定時炸彈，sql定時炸彈

一句SQL語句，可能就是一個定時炸彈，sql定時炸彈

      一句小小的SQL語句，在資料量很小的時候，可能是一句相當完美的語句。但是隨著資料量的不斷增加，你是否能想到他帶來的災難性的後果呢？那麼，什麼樣的SQL語句才算好的語句呢？

 

       對於SQL語句，很多人上來就是select *，不用想，對於資料量大的表來說，這樣的語句無非是致命的。而一個好的資料庫管理員，在設計資料庫時，就應該想到當資料量很大很大時，就應當有所準備。

 

       最近在做一個查詢統計， 因為一直用原生資料庫，資料量不是很大，即使查詢時等1s也沒什麼感覺，但是當串連到真正的資料庫上，那等待的感覺，只能用一個詞來形容。煎熬。沒辦法，這樣的系統哪個使用者敢用啊。卡都卡爆了。最後把那條SQL語句放到真實的資料庫中執行。災難來臨，直接卡死。資料庫癱瘓。資料是1秒一添加的。可想而知資料量有多大了。只能最佳化SQL語句了，光最佳化SQL語句還是不行的。還得想想其他辦法。

 

      所以，SQL語句慎用，資料庫的最佳化很重要，是每一個“優秀”程式員必須要會的。

 

      這個問題到底如何解決的呢？其實解決辦法很多，看你對資料庫的瞭解程度了。我是瞭解的不深刻，只能跟著大牛學習學習了。

 

       因為我們的資料是即時監測資料，資料更新很快，但是就是為了防止第一次啟動時沒有資料，所以進行了初始化，執行了這條SQL語句。導致我們重啟以後，可以說是再也啟不來了。它害死了整個系統。所以我們乾脆就不執行這條SQL語句了，初始化時直接給他個初值。直接斃掉。即時資料會存入字典裡，所以我們只需要在字典裡查詢我們需要的資料。

       這個辦法當然是無可奈何的。資料庫的最佳化蘊含著很深的學問。在工作中、學習中要多多積累經驗，敢於嘗試，敢於去最佳化。對於資料庫，是從2013年6月開始接觸的，但是一直停留在基礎層次，從未有所長進。我是這麼覺得的，但是回過頭來看看自己的部落格，不管是預存程序還是視圖、觸發器自己都用過，也都會用。我停留在哪了嗎？我差在哪裡了。說對了。我不會最佳化。大資料最佳化，對於我來說是個高大上的詞，我畏懼他。

 

      項目馬上快驗收了，效率這麼低，經理請來一個10年專供資料庫的人來解決效率問題，他通過表分區進行最佳化。重構了資料庫。其實這些在開發的時候就應該想到的，等項目快上線了再動資料庫確實有點不妥了。

 

     下班以後，我也百度一下，多學習一下資料庫的最佳化，這個要學好了，我也要學著讓自己成為大牛，哈哈。

 

      對於資料庫的最佳化，有很多我們需要學習的，也有很多注意的。這得在項目實踐中多多積累。我所瞭解的一丟丟，萬事都從一丟丟開始，不可能一下子一口吃個胖子。

 

     所以，對於資料庫的使用，我們要考慮很多，尤其是效能。我們要多接觸這方面的知識。比如：你是否知道select *的壞處，*無非是查詢所有列了。這是多麼耗費時間你是知道的。對於你寫的每一句SQL語句都要深思熟慮看，考慮一下後果。我們還可以減少訪問資料庫的次數，能不直接從庫裡取資料就不拿。還可以使用索引，提高檢索資料的效率，但是索引需呀儲存空間，並且要定期維護，索引要加的適量並且準確。否則不必要的索引同樣影響效率。我們還要避免在索引上使用計算。

 

     資料庫的最佳化，是我們每個人需要會的。我瞭解的太少了，得在工作中多多積累經驗，讓以後的項目中，從一開始，就把效能問題考慮進去，多一份思考。效能問題應該受到重視。

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。