前幾天自己開發的乙個系統。上線接入pinpoint 監控。發現每天網上0.30和2.0兩個時間段。有幾個介面響應非常慢大概是7s結論： 通過mybatis二級快取進行優化
通過pinpoint平台。按個介面主要的時間是消耗在執行乙個select查詢
我第一反應就是：乙個優化查詢的機會到了
然後用explain一通操作。發現因為有乙個查詢 like了""字串。那肯定是全表掃瞄。然後將語句改了。將空過濾掉了。優化後上線。發現晚上還是有查詢需要5s鐘
嘿嘿，看起來那個優化有效果。實際上，，確實有一點效果（完全是誤打誤撞）。但是原因根本就找錯了。因為其實是全表查詢，我那個表一共才幾千條資料。也不慢的
explain 分析查詢執行計畫
後面第二次分析：結合pinpoint平台。我發現慢查詢所在的時間段tps相對較高。然後我分析應該是因為表鎖的原因。因為系統裡面有個儲存文章的表是用的myisam儲存引擎，然後這個儲存引擎只有表鎖。那說明只要有在試圖更新某一行的時候。會將整個表鎖住。這就會導致我其他的查詢語句也變慢。然後我就想到了利用mybatis的快取進行優化。
原理：當有個請求是進行更新操作的時候，會鎖住整張表，導致我的查詢只能先等待。但是如果我使用快取，直接從緩訪問資料，不進行資料庫查詢。響應時間及會變短
這裡又有個知識點：當進行更新。刪除，新增操作的時候，是寫入操作完成之後（就是事務結束），再清空快取。所以我的優化是有效的。當你再寫入過程中，我的查詢直接從緩訪問資料這裡存在：寫入操作是在我的查詢之前進行。但是我查詢的快取資料是寫入完成之前的資料。因為我這裡是資訊系統。即使有些微資料不一致。完全不影響
eviction
="fifo"
flushinterval
="120000"
size
="256"
readonly
="true"
/>
總結經驗：
記一次線上OOM和效能優化
某次周五，發布前一周的伺服器小動盪?上周五，通過grafana監控，線上環境突然出現cpu和記憶體飆公升的情況 既然伺服器在某個時間點出現了高負荷，於是就先去找一開始出現問題的伺服器，去找耗時的服務，例如我當時去找資料庫耗時的服務，由於上週的日誌已經被刷掉，於是我大致描述一下 admin yyyy ...
redis配置優化 記一次線上redis問題排查
在通過redis快取進行了一系列的介面效能優化後,大部分介面返回在1ms 200ms間,這都是redis的功勞,但隨著介面redis快取越來越多,新的問題產生了,從redis取資料竟然用了5s 通過觀察日誌,並不是每次取資料都是5s,大部分情況從redis取資料還是很快的不會超過5ms.1 在檢視 ...
漫漫優化路，總會錯幾步（記一次介面優化）
最近做了乙個搜尋介面的優化，反覆壓測了四次，終於達到要求了，記錄一下，晚上加個雞腿?業務邏輯 從opensearch中檢索出資料，然後各種填充組裝資料，最後返回 邏輯看似很簡單，當初我也是這樣認為的，於是預估5天完成，最後前前後後開發 聯調 改bug直到上線差不多花了10天 當然這10天並不是只做這...