2019獨角獸企業重金招聘Python工程師標準>>>

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

如果主服務器出現故障；

由于從服務器比較多，切換從服務器最少需要半個小時的時間；而且這種從服務器很多的架構，當訪問量很大的時候，對服務器的網卡也是很大的挑戰，容易引起故障；
我們可以從監控信息來判斷影響服務器 性能的原因


磁盤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

轉載于:https://my.oschina.net/u/3530967/blog/1579307

總結

以上是生活随笔為你收集整理的什么影响了数据库的性能？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。