mysql
阿裏雲RDS MySQL遷移到同地域同規格的RDS MySQL之後，性能明顯不如遷移前的性能。最開始業務只是用戶側感覺系統卡頓，但服務器方面性能沒有任何異常，故把問題指向數據庫。以下是對這個問題的分析及處理。
排查步驟查看內存、CPU使用情況
發現cpu使用率極高，經常出現”尖刺“
排查慢SQL
對業務sql進行分析，使用explain 查看sql執行計劃
code1
可以看到 key這一列是空，但是從理論上這個值不應該爲null,因爲該表的ID列存在一個索引
使用show index from tablename 查看這張表索引情況
code2
可以發現索引的Cardinality值爲0，這代表這這個索引是無效的。也就是說執行器在執行的時候不會使用這個索引。這個值越趨近1代表選擇性越高，那麽在執行語句時，使用該索引的可能性將變高。
使用 analyze 重新計算該值
code3
不確定庫中還有其他表統計信息缺失，使用以下語句查詢缺少統計信息的表,，然後再統一執行 analyze
code4
更新統計信息後，業務sql恢複正常。使用analyze不會同步到備庫，故需要重搭備庫。造成該現象原因：在進行dts操作過程中，源庫進行了HA切換，導致某些表的統計信息還未進行持久化，姑遷到新庫的索引統計信息爲0，進而導致業務sql不走索引，最後導致cpu增高。
CPU使用率還是比較高，時常出現“尖刺”
查看業務中的慢sql對慢sql進行分析
code5
同時查看一下實例的cpu及物理讀寫（和內存相關），若讀寫較高，則調整 innodb_buffer_pool_size 參數，建議爲內存的3/4
cpu依舊偶爾存在“尖刺”
查看表碎片率
code6
若業務表碎片率較高的話，則使用optimize table 優化一下表
-----------------------------------------------
歡迎各位夥伴在評論、留言指出不足之處。
聯系方式：mr_xuansu@163.com
更多內容請關注微信公衆號：萱蘓的運維日常
