資料庫資料最佳化故事多，資料庫資料最佳化故事

資料庫資料最佳化故事多，資料庫資料最佳化故事

基礎調用評教系統介面，在運行程式時 我們看到IIS的進程居高不下。

於是想了幾個方法進行資料庫的而最佳化嘗試。

第一 加索引。

    索引是對資料庫表中一列或多列的值進行排序的一種結構，使用索引可快速存取資料庫表中的特定資訊。索引對於資料庫來說 就像目錄和整本書的關係一樣。有了資料庫索引，我們就可以先尋找目錄，然後快速的找到我們想要查詢的欄位。如果想按特定學生的姓來尋找他或她，則與在表中搜尋所有的行相比，索引有助於更快地擷取資訊。

優點：

    建立索引可以大大提高系統的效能。第一，通過建立唯一性索引，可以保證資料庫表中每一行資料的唯一性。第二，可以大大加快資料的檢索速度，這也是建立索引的最主要的原因。第三，可以加速表和表之間的串連，特別是在實現資料的參考完整性方面特別有意義。第四，在使用分組和排序子句進行資料檢索時，同樣可以顯著減少查詢中分組和排序的時間。

 

     當然，它也有不利的一面就是要注意的是，建立太多的索引將會影響更新和插入的速度，因為它需要同樣更新每個所以索引檔案。

有了上面一些基礎的理論，我們開始改革。由於上課班學生的資料量將會特別大，超過50多萬條資料。再加索引時有幾個基本的原則就是

    1加在經常搜尋的欄位上面，因為索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間；

    2加在需要按某欄位排序的上面

    3不加在值特別少的欄位上面。例如 性別只有男女兩個值。

好在資料匯入之前我們就將索引加上了。再講50萬資料匯入之後，再視圖加索引時，就提示操作逾時。。

第二 建立視圖

    這兩天操作資料庫，對錶串連有了更深的理解。之前也寫過一篇建立視圖的部落格，歡迎大家移步瞅一眼再回來。3.0最佳化查詢-引入視圖

    它沒有實際的物理紀錄也特別適合於多表串連瀏覽是使用。像我們表中，我們需要查詢一個學生上的所有課程，類型和任課老師的姓名。我們需要根據學生去班級表中查詢班級ID，再根據班級ID 去上課班和行政班表中查詢對應的上課班ID，有了上課班ID之後可以根據它去查詢上課的老師ID，然後根據上課的老師ID 去查詢老師表裡面去查詢老師的姓名。繼續根據上課班ID去查詢課程ID，然後再去課程表裡面去查詢課程的ID和名稱。最後，根據課程的ID查到課程類型ID之後去 課程類型表中查詢到課程的類型名稱。

如此一個查詢結果才顯示出來。輕巧的是，用了視圖之後呢。所有的資訊都在一個表中。直接查詢想要的欄位。

    只不過，在這裡考慮到如果我們將所有的學生的所有的課程放在一個視圖裡面，一個學期的資料量基本在30000*10以上。於是我們想到一個折中的辦法就是，一個視圖表中儲存該學生所在的班級中公用上的課。這樣就將原本50多條學生資料 縮小到一條班級資料。雖然多了一層需要根據學號去查詢班級資訊，但是也減少了查詢時間。

以上兩個最佳化是我們真正在這次的系統中操作和實踐的。關於資料庫的最佳化還有很多。

     例如應用預存程序。說到這，我們做了一個實驗，再有50萬資料的時候，寫了一條低效率的查詢語句。

如下select * from dbo.BasicTeacherEntities where TeacherID not in (select teacherID from dbo.BasicOnClassEntities where  OnClassID not in
(select OnClassID from BasicOnClassStudentEntities where StudentID ='193a83fc-558e-490c-b51f-04365a74a3be'))

   結果它第一次查詢時用了11s，但是奇怪的是，當我第二次查詢時僅用了不到1s.換一個StudentID也一樣的不用等。

是不是和預存程序原理是一樣滴？有待考究。

此外還有兩點正在研究中。資料庫的分表和資料字典前端緩衝。部落格會及時更新。