springmvc controller 查詢數據慢追蹤

問題描述

 公司後臺系統線上環境出現用戶正常使用期會出現系統慢問題,緩慢問題沒法有效解決. 領導說慢是service添加了整事物覆蓋致使，若是多線程訪問同一條記錄會有等待狀況，若是不須要只讀事物是會加快查詢,把Transcational(readOnly) 去掉

@Service
@Transactional(readOnly = true)
public class XxService

我回答是說 跟這個沒多大關係.mysql5.6之前會區分引擎 mysan與innodb 區別。如今優化愈來愈好兩個類型已經沒區別了。只讀去掉不去掉都無太大影響

本着領導檢查原則。讓我作這塊驗證說法我就作本次記錄. 若有不正確還請指出

系統是接入過 SkyWalking 的 .經過系統接入SkyWalking 進行監控查看,

 拿出頻率比較高接口慢緣由 猜想點圍繞 如下點

     1.只讀事物影響

     系統內每一個service都會開啓事物 查詢走只讀事物, 更新走讀寫事物, 而只讀事物特色在於防止數據髒讀。

     目前系統大部分業務不存在髒讀狀況。若是去掉只讀事物是否在更新同時不須要等待時間直接查詢返回而提升效率

問題分析

監控圖看到 .數據庫總量單表在1千萬左右 訪問url.

SkyWalking監控到的圖，同一個接口慢話 1-100秒響應時間不等而一條完整追蹤鏈 顯示 間隔較長 就是耗時時間較長點 都是查詢sql以前發的

select @@session.tx_read_only  再到語句過程耗時較多。若是一個接口查詢過多數據就會致使 耗時更長, 是否這個tx_read_only  額外查詢致使慢

經過 資料，找到了緣由:

    此sql的做用主要是判斷事務是否爲只讀事務。MySQL自身會對只讀事務作優化，這是MySQL5.6.5 版本之後纔出現的。http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_tx_read_only

    定位到MySQL的驅動包代碼

通常狀況下，驅動能夠保證本地值與遠程服務器值保持一致。當應用調用setAutoCommit, setTransactionIsolation 和 setReadOnly這三個接口設置參數值時，會與遠程服務器同步。

具體而言

當useLocalSessionState爲true時，若值與本地值不一致，則發往遠程更新；
當useLocalSessionState爲false時，不管設置值與本地值是否一致，每次都發往遠程更新。這能夠解釋爲何有些實例set autocommit語句比較多。

因此第一條跟這個無關係select @tx_read_only  這個只是保證本地查詢事物與mysql數據端一致作的同步,並不影響效率.

接下來是事物問題 建在本地弄了一樣級別數據量1千6百萬, 統計一下就花了23秒

再繼續添加驗證

分別添加controller,service.mybatis ,service 經過刪除Transcational標記和加上來進行測試

建立查詢線程測試幾個場景 去掉Transactionl測試查詢影響

 1.service保留Transactionl  , 查詢11個運單同時開啓3個線程 耗時 1:08, 1:06 , 1:06, 進行讀寫讀測試 a個線程先讀(結果:test1)，b線程開始寫(結果:test2)，c線程再讀(結果:test1)，d線程跟讀(結果:test1). 分別時間未 1:18,1:24, 1:16,1:16

 2.service去掉Transactionl ,  查詢11個運單同時開啓3個線程 耗時 1:09 ,1:10, 1:10, 進行讀寫讀測試 a個線程先讀(結果:test1)，b線程開始寫(結果:test2)，c線程再讀(結果:test1)，d線程跟讀(結果:test1). 分別時間未 1:17,1:25, 1:15,1:14

在jdbc加上默認tx_read_only，及去掉Transactionl測試影響結果同上

結論總結

 查閱衆多資料及驗證。mysql默認事物隔離( Repeatable read )基本驗證基本一致,存在鎖狀況通常爲更高基本事物隔離( Serializable )

 而service 加Transactionl 是一種規範問題。加上Transactionl (readonly=false) 表示會默認優化事物只讀. 若是不加 則默認讀寫事物, 細化到方法未寫readonly遺忘也不要緊.

優化數據庫查詢只能更改mysql數據幾個事物級別再次下降。及庫語句優化,緩存處理.咱們這個緩存也沒少加.系統整體體量過大 查詢統計語句過多。服務器資源有限. 若是在其餘地方瘦身後。使依賴查詢數據庫頻率下降，資源也就出來了。不會致使日常走索引單條几條查詢出現 響應時間長短不一結果.