基礎調用評教系統接口，在運行程序時 我們看到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也一樣的不用等。
是不是和存儲過程原理是一樣滴？有待考究。
