真兇
謹慎起見，我并沒有馬上將索引應(yīng)用到生產(chǎn)的JT數(shù)據(jù)庫上面，晚上12點，再次登陸數(shù)據(jù)庫服務(wù)器，查看以下CPU的負載，把我嚇了一跳。負載還是那么高，按我們的經(jīng)驗晚上該數(shù)據(jù)庫服務(wù)應(yīng)該是非?？臻e的，為什么還會有這么大的負載呢。
馬上打開活動監(jiān)視器，發(fā)現(xiàn)結(jié)果還是和以前的一樣，還是jt_user的用戶CPU和IO，但是晚上jt_user對應(yīng)的應(yīng)用系統(tǒng)應(yīng)該沒有人用。
馬上打開SQL Profiler，事件僅選BatchCompleted，將CPU的閥值設(shè)為5，Duration的閥值設(shè)為10，這個閥值其實已經(jīng)很低的了，也就晚上12點我才敢這么設(shè)定。
結(jié)果收集的結(jié)果嚇我一跳，在短短的13分鐘內(nèi)，竟然同一條語句執(zhí)行了1479次。
select top 1 end_time from Log_Network_circs order by end_time desc
Log_Network_circs這張表有2657563條記錄，平均每秒查詢1.89次，每分鐘查詢113.8次，說白了就是秒對一個265萬條記錄的表進行排序。而且這條語句明顯能寫成：
select max(end_time) from Log_Network_circs
又短效率比原來的還高，想不明白。以下是統(tǒng)計信息。
表 ’Log_Network_circs’。掃描計數(shù) 3，邏輯讀取 16352 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
SQL Server 執(zhí)行時間:
CPU 時間 = 1156 毫秒，占用時間 = 619 毫秒。
更要命的是，我發(fā)現(xiàn)這個表的記錄數(shù)是時刻增長的，每秒4~5條。insert 語句肯定肯定是讓我那個這么低的閥值過濾掉了。
這個明顯屬于應(yīng)用系統(tǒng)設(shè)計的問題，找開發(fā)商聊了。
不是辦法的辦法
與開發(fā)商聯(lián)系后，問清楚情況，確認該表的數(shù)據(jù)可以刪除，以防萬一，將數(shù)據(jù)庫備份，然后truncate了這個表。但是這個不是一個的解決辦法，我個人認為該問題應(yīng)該在應(yīng)用層上面解決。我向開發(fā)商提出了以下幾點建議：
1。將查詢的頻率調(diào)低一點。
2。select max(end_time) from Log_Network_circs 能比原來這條語句性能好很多，如果只是為了查最后一條。
3。直接寫個觸發(fā)器，在插入的時候把end_time存到別的表里面去，然后在這個表里面取end_time的值。
4。定時執(zhí)行清空這個表的數(shù)據(jù)。
謹慎起見，我并沒有馬上將索引應(yīng)用到生產(chǎn)的JT數(shù)據(jù)庫上面，晚上12點，再次登陸數(shù)據(jù)庫服務(wù)器，查看以下CPU的負載，把我嚇了一跳。負載還是那么高，按我們的經(jīng)驗晚上該數(shù)據(jù)庫服務(wù)應(yīng)該是非?？臻e的，為什么還會有這么大的負載呢。
馬上打開活動監(jiān)視器，發(fā)現(xiàn)結(jié)果還是和以前的一樣，還是jt_user的用戶CPU和IO，但是晚上jt_user對應(yīng)的應(yīng)用系統(tǒng)應(yīng)該沒有人用。
馬上打開SQL Profiler，事件僅選BatchCompleted，將CPU的閥值設(shè)為5，Duration的閥值設(shè)為10，這個閥值其實已經(jīng)很低的了，也就晚上12點我才敢這么設(shè)定。
結(jié)果收集的結(jié)果嚇我一跳，在短短的13分鐘內(nèi)，竟然同一條語句執(zhí)行了1479次。
select top 1 end_time from Log_Network_circs order by end_time desc
Log_Network_circs這張表有2657563條記錄，平均每秒查詢1.89次，每分鐘查詢113.8次，說白了就是秒對一個265萬條記錄的表進行排序。而且這條語句明顯能寫成：
select max(end_time) from Log_Network_circs
又短效率比原來的還高，想不明白。以下是統(tǒng)計信息。
表 ’Log_Network_circs’。掃描計數(shù) 3，邏輯讀取 16352 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
SQL Server 執(zhí)行時間:
CPU 時間 = 1156 毫秒，占用時間 = 619 毫秒。
更要命的是，我發(fā)現(xiàn)這個表的記錄數(shù)是時刻增長的，每秒4~5條。insert 語句肯定肯定是讓我那個這么低的閥值過濾掉了。
這個明顯屬于應(yīng)用系統(tǒng)設(shè)計的問題，找開發(fā)商聊了。
不是辦法的辦法
與開發(fā)商聯(lián)系后，問清楚情況，確認該表的數(shù)據(jù)可以刪除，以防萬一，將數(shù)據(jù)庫備份，然后truncate了這個表。但是這個不是一個的解決辦法，我個人認為該問題應(yīng)該在應(yīng)用層上面解決。我向開發(fā)商提出了以下幾點建議：
1。將查詢的頻率調(diào)低一點。
2。select max(end_time) from Log_Network_circs 能比原來這條語句性能好很多，如果只是為了查最后一條。
3。直接寫個觸發(fā)器，在插入的時候把end_time存到別的表里面去，然后在這個表里面取end_time的值。
4。定時執(zhí)行清空這個表的數(shù)據(jù)。