歡迎光臨
每天分享高質量文章

什麼影響了資料庫查詢速度?

  • 1 影響資料庫查詢速度的四個因素
  • 2 風險分析
  • 3 網卡流量:如何避免無法連接資料庫的情況
  • 4 大錶帶來的問題(重要
  • 5 大事務帶來的問題(重要

1 影響資料庫查詢速度的四個因素

clipboard.png

2 風險分析

QPS:Queries Per Second意思是“每秒查詢率”,是一臺服務器每秒能夠相應的查詢次數,是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。

TPS:TransactionsPerSecond的縮寫,也就是事務數/秒。它是軟體測試結果的測量單位。客戶機在發送請求時開始計時,收到服務器響應後結束計時,以此來計算使用的時間和完成的事務個數。

 Tips:最好不要在主庫上資料庫備份,大型活動前取消這樣的計劃。

  1. 效率低下的sql:超高的QPSTPS
  2. 大量的併發:資料連接數被占滿(max_connection預設100,一般把連接數設置得大一些)。
    併發量:同一時刻資料庫服務器處理的請求數量
  3. 超高的CPU使用率:CPU資源耗盡出現宕機。
  4. 磁盤IO:磁盤IO性能突然下降、大量消耗磁盤性能的計劃任務。解決:更快磁盤設備、調整計劃任務、做好磁盤維護。

3 網卡流量:如何避免無法連接資料庫的情況

  1. 減少從服務器的數量(從服務器會從主服務器複製日誌)
  2. 進行分級快取(避免前端大量快取失效)
  3. 避免使用select * 進行查詢
  4. 分離業務網絡和服務器網絡

4 大錶帶來的問題(重要

4.1 大表的特點

  1. 記錄行數巨大,單表超千萬
  2. 表資料檔案巨大,超過10G

4.2 大表的危害

1.慢查詢:很難在短時間內過濾出需要的資料
查詢字區分度低 -> 要在大資料量的表中篩選出來其中一部分資料會產生大量的磁盤io -> 降低磁盤效率

2.對DDL影響:

 建立索引需要很長時間:

  • MySQL -v<5.5 建立索引會鎖表
  • MySQL -v>=5.5 建立索引會造成主從延遲(mysql建立索引,先在組上執行,再在庫上執行)

 修改表結構需要長時間的鎖表:會造成長時間的主從延遲(‘480秒延遲’)

4.3 如何處理資料庫上的大表

分庫分表把一張大表分成多個小表

 難點:

  1. 分表主鍵的選擇
  2. 分表後跨分割槽資料的查詢和統計

5 大事務帶來的問題(重要

5.1 什麼是事務

clipboard.png

5.2 事務的`ACID`屬性

1、原子性(atomicity):全部成功,全部回滾失敗。銀行存取款。

2、一致性(consistent):銀行轉賬的總金額不變。

3、隔離性(isolation):

 隔離性等級:

  • 未提交讀(READ UNCOMMITED臟讀,兩個事務之間互相可見;
  • 已提交讀(READ COMMITED)符合隔離性的基本概念,一個事務進行時,其它已提交的事物對於該事務是可見的,即可以獲取其它事務提交的資料。
  • 可重覆讀(REPEATABLE READInnoDB的預設隔離等級。事務進行時,其它所有事務對其不可見,即多次執行讀,得到的結果是一樣的!
  • 可串行化(SERIALIZABLE) 在讀取的每一行資料上都加鎖,會造成大量的鎖超時和鎖徵用,嚴格資料一致性且沒有併發是可使用。

 查看系統的事務隔離級別:show variables like '%iso%';
開啟一個新事務:begin;
提交一個事務:commit;
修改事物的隔離級別:set session tx_isolation='read-committed';

4、持久性(DURABILITY):從資料庫的角度的持久性,磁盤損壞就不行了

clipboard.png

 redo log機制保證事務更新的一致性持久性

5.3 大事務

運行時間長,運算元據比較多的事務;

 風險:鎖定資料太多,回滾時間長,執行時間長。

  1. 鎖定太多資料,造成大量阻塞和鎖超時;
  2. 回滾時所需時間比較長,且資料仍然會處於鎖定;
  3. 如果執行時間長,將造成主從延遲,因為只有當主服務器全部執行完寫入日誌時,從服務器才會開始進行同步,造成延遲。

 解決思路:

  1. 避免一次處理太多資料,可以分批次處理;
  2. 移出不必要的SELECT操作,保證事務中只有必要的寫操作。

赞(0)

分享創造快樂