前言：前幾天在用jmeter做性能測試的時候，遇到一個響應時間長的性能問題，簡單總結一下，分享給大家，希望能給大家在性能測試過程中類似問題提供一個性能問題分析定位的思路。
現象如下圖，響應時間很長，達到了18秒左右，tps也只有20。
根據經驗，直奔oracle數據庫服務器，top命令一看，負載高，用戶cpu將近100%，cpu已經達到性能瓶頸了，shift+p，或者鍵盤大寫狀態下按P，將所有進程按cpu使用率從高到低排序，這樣，我們關注消耗cpu最多的進程即可。
直接選取上圖第一個進程ID27087，通過下面的sql在plsql中查詢（注意：連接oracle數據庫的用戶需要有v$process、v$session、v$sql這3張表的權限，如果沒有，向DBA申請即可，下面sql的含義：通過pid，在v$process中找到paddr，通過paddr在v$session中找到sql_id，通過sql_id在v$sql中找到對應的sql）
可以看到完整的sql語句，是一個多表關聯查詢語句，它很耗數據庫cpu，順其自然的想到去看下錶的索引。
查看錶，發現where後條件字段不是索引字段。
編輯表，果斷把該字段加爲索引字段，重新壓測，數據庫服務器基本上就沒啥負載了，且cpu基本都是空閒狀態。
響應時間也只有幾十毫秒了
tps從20左右提升到300多，可以說性能提升是相當的明顯
總結：sql一直佔用cpu切片時間，其它線程就只能等待，服務器負載高，所以響應時間就長了。