什麼影響了數據庫的性能？

老師曾經從業過的一家電商公司，

若是主服務器出現故障；

因爲從服務器比較多，切換從服務器最少須要半個小時的時間；並且這種從服務器不少的架構，當訪問量很大的時候，對服務器的網卡也是很大的挑戰，容易引發故障；
咱們能夠從監控信息來判斷影響服務器 性能的緣由


磁盤IO用的是fashion IO

凌晨，讀的峯值很大（可能說明服務器性能急劇降低），檢查後，由於是數據庫備份遠程同步計劃任務形成的。

併發量：同一時間處理的請求的數量
TPS - Transactions Per Second（每秒傳輸的事物處理個數），這是指服務器每秒處理的事務數，支持事務的存儲引擎如InnoDB等特有的一個性能指標。
計算方法：
TPS = (COM_COMMIT + COM_ROLLBACK)/UPTIME

use information_schema;  
select VARIABLE_VALUE into @num_com from GLOBAL_STATUS where VARIABLE_NAME ='COM_COMMIT';  
select VARIABLE_VALUE into @num_roll from GLOBAL_STATUS where VARIABLE_NAME ='COM_ROLLBACK';  
select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME ='UPTIME';  
select (@num_com+@num_roll)/@uptime;

• 1
• 2
• 3
• 4
• 5

QPS - Queries Per Second（每秒查詢處理量）同時適用與InnoDB和MyISAM 引擎
計算方法：
QPS=QUESTIONS/UPTIME

use information_schema;  
select VARIABLE_VALUE into @num_queries from GLOBAL_STATUS where VARIABLE_NAME ='QUESTIONS';  
select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME ='UPTIME';  
select @num_queries/@uptime;

• 1
• 2
• 3
• 4

詳情：http://blog.csdn.net/wind19/article/details/8600083

mysql目前並不支持多CPU，只支持單CPU；

大促來襲，訪問量急速增長，對於超高的QPS和TPS,效率低下的sql是很大的風險，
大部分數據庫問題都是因爲慢查詢形成的，也就是說能夠優化sql來解決問題；

這裏的併發是鏈接數；
發生在熱數據遠遠大於服務器可用內存的狀況下

主備份遷移到從備份，磁盤報警及時處理





comment：備註，這個數據表記錄上億

來源只有四個，要從上億找一小部分數據，將產生大量的磁盤IO;

單線程的問題

好比頻繁更新的訂單日誌表，若是在更新時修改表結構，會致使數據鏈接數忽然猛增，鏈接數被沾滿，500錯誤，boss頂你個肺；
解決思路：傳說中的分庫分表


大事務帶來的問題


失敗，所有操做回滾；

已提交讀（不重複讀）和重複讀的區別是
重複讀（一個用戶在其事務沒有結束時不能夠獲得另外一個用戶已經執行完的事務的結果），可是已提交讀是能夠的。
（隔離性最高，併發性最低）串行化會在讀取的每一行上多加鎖，因此可能會出現比較多的鎖超時事件
事務的持久性（DURABILITY）

查看事務的結構
show variables like '%iso%';
更改事務結構
set session tx_isolation='事務類型';

• 1
• 2
• 3
• 4