情況：上週，公司一專案新上線，剛上線的第2天，在後台發現資料庫伺服器與iis伺服器的網路io出現瓶頸，1gb的網路頻寬，占用了70%-100%，也就是每秒傳輸資料700mb-1gb，資料庫使用記憶體高達21gb。
iis伺服器cpu使用率時常爆至80%-90%，導致**頻頻出現連線超時。
原因select
*from table1
這條語句，語法是沒問題的，但在應用上出了問題。table1儲存的是10多萬行資料，表資料每天都會上萬的增長。
為了統計總行數，頻頻呼叫這語句，每秒重新整理不低於1000次。
也因此導致網路出現瓶頸。
解決：後面把select語句改成
select
count(*) from table1
即可解決問題，網路 io資料馬上降至10mb以下，資料庫使用記憶體也保持在預計範圍12gb。
看似非常簡單的問題，其實不然。解決這問題，所花的時間週期是6小時，檢查問題使用1小時，修改**使用5小時。
小結：
做事要細心，不要犯低階錯誤，有時候成功取決於細節。
一條select語句引起的瓶頸問題思考
情境還原 公司一專案新上線，剛上線的第2天，在後台發現程式設計客棧資料庫伺服器與iis伺服器的網路io出現瓶頸，1gb的網路頻寬，占用了70 100 也就是每秒傳輸資料700mb 1gb，資料庫使用記憶體高達21gb。iis伺服器cpu使用率時常爆至80 90 導致 頻頻出現連線元程式設計客棧時。原...
一條select語句的旅遊過程
待分析sql語句 select from t where id 10 來自於一篇好文 1 和聯結器打交道 第一步，連線到資料庫上，此時負責接待的就是聯結器。它的職責就是建立連線 獲取許可權 維持和管理連線。mysql h ip p port u user p 注意 連線建立好後，如果沒有後續動作，連...
一條insert語句導致的效能問題分析（二
今天對之前描述的問題 一條insert語句導致的效能問題分析 一 進行了進一步的補充。有一條insert語句的主要效能瓶頸在於insert子句中的查詢語句，查詢中的主要資源消耗在於對兩個表進行了多次關聯 語句主要的結構如下 insert into xx select from test vip ne...