記一次年前，效能測試組人員，給我測試出的bug吧，說實話，這種bug也只有在高併發情況下才會出現。
說下業務背景，我的程式中有一段邏輯是這樣設計的：使用者第一次請求，我會根據使用者的請求條件，用雜湊演算法算出乙個 雜湊值，再將使用者的請求條件插入的到一張表裡；然後拿查詢條件去請求其他系統（耗時較長）和查詢本地資料庫裡的業務表（資料量較大），這樣查詢完後，會將兩部分的資料彙總到一張結果表裡，然後再從結果表中將資料統一查出返回給呼叫系統。
原本這也沒啥問題，測試幾輪下來，除了資料質量問題（與程式無關），沒有出現過其他狀況。直到效能測試，給我搞的很難受。
效能測試很重要得乙個指標就是 tps，還有在併發情況下，伺服器各項指標是否正常。
測試人員在將併發數調整到400後，持續1小時壓測，進行到5分鐘時，突然 tps斷崖式下降至200，再5分鐘100。同時資料庫 cpu top命令下，cpu達到90。相當不正常，不正常了，就需要去排查。
排查主要集中在兩點：1.測試哪個介面2.為什麼5分鐘tps規律性的下降。
程式中5分鐘有乙個定時任務會進行清理操作，這部分操作會對查詢的表進行 update、delete操作，但是我分析這張表總的資料量也就10w條左右，可能並不會影響；然後事實跟我想的正好相反，恰好就是這張不起眼的表導致的資料庫cpu被沾滿。緊接著說下排查過程、優化過程。
使用top命令時，可以看到有個程序佔用率特別高 複製它的程序 id
process
然後進入到到資料庫中 執行語句 select * from v$process where spid=程序號
select * from v$session where paddr=「位址」
select* from v$sql where sql_id=『上面查出的sqlid』；
即可找到對應消耗cpu較多的sql語句。結果就是我剛才說的只有10w左右資料量的sql。
單純執行這個sql並不會耗費多少資源，但是一旦併發查詢的話，就很多了，因為我看他執行計畫時全表掃瞄，這種即使10w條資料，高併發情況下，耗費資源依然很嚴重，一定要注意。
測試資料庫腳步
執行 sql，以資料庫管理員身份登入，下面給出測試資料庫的指令碼 需要鍛鍊動手能力的朋友，可以執行它！create database teaching gouse teaching gocreate table student sno char 10 primary key,sname char 8...
junit 測試資料庫
問題一 到底插不插進資料庫 由於測試資料有時比較隨意，插入資料庫會對資料庫進行汙染。我們在測試的時候通過控制事務，一般不提交至資料庫。例如通過spring控制事務提交，預設讓其回滾 transactionconfiguration defaultrollback true,transactionma...
php測試資料庫
echo hello word 測試能不能解析php echo date y m d h i s 測試開發環境的時間對不對 echo 四個引數 資料庫的服務位址 資料庫賬號 密碼 資料庫名稱 db new mysqli localhost root root z 0222 mysqli connec...