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