過一段時間，學一些技術，有一些進步，就把網(wǎng)站程序修改一翻。

這次修改網(wǎng)站，工程是比較大的，因為把很多數(shù)據(jù)結構重新改了，一些數(shù)據(jù)表都添加新的字段，類的方法大都重新寫過。也改進了一些功能，比如應網(wǎng)警的要求，紀錄會員每一次登錄的IP，以及每一次發(fā)布帖子的IP，甚至評論，留言的IP都有紀錄。也有很多在總結網(wǎng)友的建議和意見基礎上，進行的一些修改，如樓主可以針對網(wǎng)友的評論直接回復，還有會員發(fā)表文章，不再局限于之前系統(tǒng)限制的文章類別，可以添加自己定義的文章類別等。

但是新的測試版本一傳上去，就出現(xiàn)一個很大的問題，就是速度特別慢。后來檢查原因，是CPU占用率居高不下，常常達到100%不下來。查看進程，竟然是SQL服務器占用的CPU資源。這不是攻擊也不是病毒，是自己寫的一些SQL語句優(yōu)化不好導致的。

想了很多原因，一一去調(diào)試，甚至直接刪除了很多頁面，獨留下幾個文章頁面，問題還是一樣。有段時間都快崩潰了，問了很多人，都只是說SQL語句引起的，卻找不到是哪些語句。

只好一個頁面一個頁面去測試。這樣一來，就等于又要一切從頭來過，加起來有成千上萬行的代碼，可以說是一條條去不斷測試。終于在第三天，發(fā)現(xiàn)占用CPU資源的語句，竟然是一個返回用戶頭像的循環(huán)語句。

這個語句很重要，因為在每篇文章后面的評論，在循環(huán)調(diào)用評論的數(shù)據(jù)同時，也會循環(huán)去會員頭像表里，去判斷他的頭像是否上傳，是否上傳了還在審核，或者是已經(jīng)審核過的。就是這樣一些循環(huán)里套用循環(huán)的查詢，導致SQL服務器占用CPU資源居高不下，把這個會員頭像取消掉，一律默認成審核過的，然后用JS，在客戶端去判斷是否有添加圖片，這樣測試了好幾天，終于是正常了。但這樣會員上傳了頭像，還在審核中的提示，卻做不到了。

奇怪的是，這種情況在Access版本里的程序，卻是可以使用的，不過可能那個版本的流量不大。但是把這個SQL版本改好之后，那個也要改成用JS在客戶判斷。

如是耽誤了好幾天，把所有計劃打亂了，很多頁面都需要重新一個一個測試，有一些還要重做。我會爭取先把文章系統(tǒng)做好。