MySQL使用現狀分析與優化

前言

再緊張的裁人氛圍，也不應影響你學習的心態。不要本末倒置，技術永遠不會落後，只要你還在學習的道路上，沒有後退。

 

數據庫架構

目前生產環境RDS是多區可用架構。數據庫實例發生計劃內或計劃外的中斷時， Amazon RDS 會自動切換到另外一個可用區中的備用副本。

完成故障轉移所用的時間取決於在主數據庫實例變爲不可用時的數據庫狀態和一些其它因素如監控。故障轉移時間一般爲 60-120 秒。

事務較多或時間較長的恢復過程可能延長故障轉移時間

 

一次生產事件案例

 

全表掃描

建議：

1. object_id 列添加索引

ALTER TABLE bi_bobject ADD INDEX idx_object_id (object_id) ;

 

 低效索引

 

 

p_custom_data_453

增長索引前

增長索引後

 

索引優化建議 p_custom_data_

 

 

 低效查詢【SELECT *】

 

沒法利用覆蓋索引

無用的列會浪費寶貴的系統資源(網絡、內存、MySQL解析)

 

執行計劃 DEPENDENT SUBQUERY

優化效果

 

執行計劃中必定要避免DEPENDENT SUBQUERY！！

 

系統異常行爲

 

 a_account索引優化建議

 

 

大表索引優化

SQL優化

 

 

改進方向

 

 

做者：含笑半步顛√

博客連接：https://www.cnblogs.com/lixy-88428977

聲明：本文爲博主學習感悟總結，水平有限，若是不當，歡迎指正。若是您認爲還不錯，歡迎轉載。轉載與引用請註明做者及出處。