1.1 影響數據庫查詢速度的四個因素前端
1.2 風險分析mysql
QPS: QueriesPerSecond意思是「每秒查詢率」,是一臺服務器每秒可以相應的查詢次數,是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。sql
TPS: 是 TransactionsPerSecond的縮寫,也就是事務數/秒。它是軟件測試結果的測量單位。客戶機在發送請求時開始計時,收到服務器響應後結束計時,以此來計算使用的時間和完成的事務個數。數據庫
Tips: 最好不要在主庫上數據庫備份,大型活動前取消這樣的計劃。緩存
1.3 網卡流量:如何避免沒法鏈接數據庫的狀況性能優化
1.4 大表帶來的問題( 重要)服務器
1.4.1 大表的特色網絡
1.4.2 大表的危害session
1.慢查詢:很難在短期內過濾出須要的數據 查詢字區分度低 -> 要在大數據量的表中篩選出來其中一部分數據會產生大量的磁盤 io -> 下降磁盤效率多線程
2.對 DDL影響:
創建索引須要很長時間:
修改表結構須要長時間的鎖表:會形成長時間的主從延遲('480秒延遲')
1.4.3 如何處理數據庫上的大表
分庫分表把一張大表分紅多個小表
難點:
1.5 大事務帶來的問題( 重要*)*
1.5.1 什麼是事務
1.5.2事務的 ACID屬性
一、原子性( atomicity):所有成功,所有回滾失敗。銀行存取款。
二、一致性(consistent):銀行轉帳的總金額不變。
三、隔離性(isolation):
隔離性等級:
查看系統的事務隔離級別: show variables like'%iso%';
開啓一個新事務: begin;
提交一個事務: commit;
修改事物的隔離級別: setsession tx_isolation='read-committed';
四、持久性( DURABILITY):從數據庫的角度的持久性,磁盤損壞就不行了
redolog機制保證事務更新的一致性和持久性
1.5.3 大事務
運行時間長,操做數據比較多的事務;
風險:鎖定數據太多,回滾時間長,執行時間長。
解決思路:
2.1 影響性能的幾個方面
2.2 MySQL體系結構
分三層:客戶端->服務層->存儲引擎
2.3 InnoDB存儲引擎
MySQL5.5及以後版本默認的存儲引擎: InnoDB。
2.3.1 InnoDB使用表空間進行數據存儲。
show variables like'innodb_file_per_table
若是innodbfileper_table 爲 ON 將創建獨立的表空間,文件爲tablename.ibd;
若是innodbfileper_table 爲 OFF 將數據存儲到系統的共享表空間,文件爲ibdataX(X爲從1開始的整數);
.frm :是服務器層面產生的文件,相似服務器層的數據字典,記錄表結構。
2.3.2 (MySQL5.5默認)系統表空間與( MySQL5.6及之後默認)獨立表空間
強烈創建對Innodb 使用獨立表空間,優化什麼的更方便,可控。
2.3.3 系統表空間的錶轉移到獨立表空間中的方法
或者 Altertable 一樣能夠的轉移,可是沒法回收系統表空間中佔用的空間。
2.4 InnoDB存儲引擎的特性
2.4.1 特性一:事務性存儲引擎及兩個特殊日誌類型:Redo Log 和 Undo Log
Redo Log: 實現事務的持久性(已提交的事務)。 Undo Log: 未提交的事務,獨立於表空間,須要隨機訪問,能夠存儲在高性能io設備上。
Undo日誌記錄某數據被修改前的值,能夠用來在事務失敗時進行 rollback; Redo日誌記錄某數據塊被修改後的值,能夠用來恢復未寫入 data file的已成功事務更新的數據。
2.4.2 特性二:支持行級鎖
2.5 什麼是鎖
2.5.1 鎖
2.5.2 鎖類型
2.5.3 鎖的粒度
MySQL的事務支持不是綁定在MySQL服務器自己, 而是與存儲引擎相關
將table_name加表級鎖命令: locktable table_name write; 寫鎖會阻塞其它用戶對該表的‘讀寫’操做,直到寫鎖被釋放: unlock tables;
2.5.4 阻塞和死鎖
(1)阻塞是因爲資源不足引發的排隊等待現象。 (2)死鎖是因爲兩個對象在擁有一份資源的狀況下申請另外一份資源,而另外一份資源剛好又是這兩對象正持有的,致使兩對象沒法完成操做,且所持資源沒法釋放。
2.6 如何選擇正確的存儲引擎
參考條件:
總結: Innodb 大法好。
注意: 儘可能別使用混合存儲引擎,好比回滾會出問題在線熱備問題。
2.7 配置參數
2.7.1 內存配置相關參數
肯定可使用的內存上限。
內存的使用上限不能超過物理內存,不然容易形成內存溢出;(對於32位操做系統,MySQL只能試用3G如下的內存。)
肯定MySQL的 每一個鏈接 單獨 使用的內存。
注意: 以上四個參數是爲一個線程分配的,若是有100個鏈接,那麼須要×100。
MySQL數據庫實例:
①MySQL是 單進程多線程(而oracle是多進程),也就是說 MySQL實例在系統上表現就是一個服務進程,即進程;
②MySQL實例是線程和內存組成,實例纔是真正用於操做數據庫文件的;
通常狀況下一個實例操做一個或多個數據庫;集羣狀況下多個實例操做一個或多個數據庫。
如何爲緩存池分配內存:
Innodb_buffer_pool_size,定義了Innodb所使用緩存池的大小,對其性能十分重要,必須足夠大,可是過大時,使得Innodb 關閉時候須要更多時間把髒頁從緩衝池中刷新到磁盤中;
總內存-(每一個線程所須要的內存*鏈接數)-系統保留內存
key_buffer_size,定義了MyISAM所使用的緩存池的大小,因爲數據是依賴存儲操做系統緩存的,因此要爲操做系統預留更大的內存空間;
select sum(index_length) from information_schema.talbes where engine='myisam'
注意: 即便開發使用的表所有是Innodb表,也要爲MyISAM預留內存,由於MySQL系統使用的表仍然是MyISAM表。
max_connections 控制容許的最大鏈接數, 通常2000更大。
不要使用外鍵約束保證數據的完整性。
2.8 性能優化順序
從上到下: