一般來說，調優的第一手資料中，如何根據報告來判斷是哪些sql消耗了最多的系統資源?哪些sql是最需要調整的呢?這裡給出了乙個大致的優化思路。
一般來說，需要關注下面四種top sql
我們知道，乙個語句的響應時間有個很著名的公式：
響應時間=服務時間+等待時間
其中服務時間就是cpu為執行該語句花費的時間。
服務時間=分析時間+遞迴時間+執行時間
分析時間是cpu用於分析語句的時間，遞迴時間是cpu用於語句的遞迴sql的時間，剩下的則就是cpu用於執行語句的真正時間了。
那麼，上面的這些時間資訊從**來的?oracle提供的系統統計資訊中就有部分的時間統計資訊：
那麼，執行時間就可以根據上面三個統計資訊計算得出：
執行時間=cpu used by this session – parse time cpu – recursive cpu usage
那麼，根據上面列出的乙個簡單的原則，我們需要關注三個關於cpu時間的統計資訊: cpu used by this session, parse time cpu和recursive cpu usage，以及top5等待事件中和io相關的等待時間。如果是其他的一些等待事件出現在top5中，那麼可能需要根據不同的等待事件來分析原因了。然後優先調優時間消耗最多的相關sql。
除了上面的sql ordered by gets(邏輯io最多)，sql ordered by parse calls(軟解析過多)，sql ordered by reads(物理io過多)，statspack還按照其他的一些方式列出了top sql，這些top sql在某些情況下都是需要給予特別關注的。比如：
sql ordered by executions 執行次數超過100的
sql ordered by sharable memory 占用library cache超過1m的
sql ordered by version count 子cursor超過20的
如果沒有statspack，那麼根據v$sysstat/v$sesstat中的統計資訊，結合v$sql/v$sqlarea，一樣可以得到相關的sql。
v$sql對於每乙個子cursor都有一行統計記錄，而v$sqlarea則對同乙個父cursor只有一行統計記錄，也就是v$sqlarea是對v$sql按照父cursor進行group by後的乙個結果。這兩個檢視中都有諸如buffer_gets,parse_calls,disk_reads,,executions,sharable_mem等列，和報告列出top sql的條件對應。
JVM效能調優（一般）
鏈結 監控cpu 監控記憶體 發現發生full gc 可能存在大物件，案例 用乙個物件統計老師發表的 如果乙個老師發表很多，可能造成這個物件很大，大物件直接進入老年代，如果堆記憶體很大，full gc時間就很長。部署多個web容器，減少單個web容器的堆記憶體。場景 簡單抓取系統，抓取 上的一些資料...
資料庫 sql調優思路
經常都會被問到或者與遇到資料庫調優的問題，我的一般思路如下 1 首先是資料量，需不需要分庫分表 2 第二是需不需要使用快取技術，快取一些熱資料。3 第三是sql優化，如果sql太複雜了，那我一般會用到explain分析sql的執行計畫，優化sql 4 第四選擇索引 5 還有些讀寫分離 網路頻寬的東西...
軟體除錯的一般思路
解決軟體的bug就像警察破案一樣。警察在掌握了案件發生的時間地點和相關人物後進行分析推理，採訪相關人員，排除嫌疑人，最終找到 同樣的，軟體開發人員在接到bug時，也是分析bug發生的背景，然後在運用各種方法來找出問題的原因。並不是所有的bug都能一眼看出問題發生在哪個地方。雖然bug發生的原因千差萬...