A. mysql資料庫伺服器CPU負載超過200%，mysqld進程導致的，如何解決
可以先使用 uptime 命令查看 CPU 平均負載
那個 2 users 表示用戶連接數，指的是總連接數。
那個 load average 就是系統平均負載，1 分鍾、5 分鍾、15 分鍾系統負載的平均值。
指的是一段時間內 CPU 正在處理以及等待 CPU 處理的進程數之和的統計信息，也就是 CPU 使用隊列的長度的統計信息。這個數字越小越好。
然後再用 vmstat 命令看下 CPU 是否飽和
這裡面的 r 就是等待 CPU 的進程數，可以用來判定 CPU 是否飽和，當 r 值高於 CPU 數時，就意味著飽和了。
最右邊那個 us，sy，id，wa，st 表示所有 CPU 的使用百分比。它們分別是 user time，system time，idle，wait I/O 和 steal time 的縮寫。將 us 和 sy 的百分比加和，可以確定 CPU 是否處於忙碌狀態。
如果是多核的機器還可以使用 mpstat 命令查看是否均衡
與 CPU 相關的命令還有 pidstat
這個命令展示了 CPU 消耗在了哪些進程上面，消耗過大的進程需要格外關注下。
基本上你使用上述幾個命令 就可以初步了解 CPU 出現了何種問題
有了猜測的方向之後 你就可以進一步深入去排查了
B. 如何解決高並發場景下，緩存冷啟動導致mysql負載過高，甚至瞬間被打死的問題
由於mysql是一個連接給一個線程，當並發高的時候，每秒需要幾百個甚至更多的線程，其中創建和銷毀線程還好說，大不了多耗費點內存，線程緩存命中率下降還有創建銷毀線程的性能增加問題---這個問題不是特別大，重點是mysql底層瞬間處理這幾百個線程提交的sql（有時候一個頁面會有10多條sql，cpu一次只能處理一條sql）會導致cpu的上下文切換，性能抖動，然後性能下降。
C. oracle資料庫負載不均衡怎麼辦
你是否做了資料庫的讀寫分離？如果沒做 沒辦法 如果做了通過負載均衡設備 可以做資料庫讀的負載均衡 寫的做不了
D. 資料庫中數據冗餘會產生什麼問題
數據冗餘的缺點：
1、存儲空間的浪費。
2、數據交互和資料庫訪問執行效率降低。
但適當的數據冗餘又能加快查詢。數據冗餘究竟是好是壞還是要根據自己所做的項目進行合理的取捨。
當同一數據塊存儲在兩個或多個單獨的位置時, 就會發生數據冗餘。假設創建了一個資料庫來存儲銷售記錄, 並在每個銷售的記錄中輸入客戶地址。但是，有多個銷售到同一客戶，因此同一地址被多次輸入。重復輸入的地址是冗餘數據。
(4)資料庫負載出現的問題擴展閱讀
一定的冗餘可以提升性能
1、空間換時間
有一張字典表 city 其中有 id 和 cityName 兩個欄位，有一張業務表，其中有 id 、cityId、XXX、XXX…欄位。如果查詢業務表的話，就必須 join 一下 city 字典表，如果業務表很大很大，那麼就會查詢的很慢，這個時候我們就可以使用冗餘來解決這個問題。
直接將業務表中的 cityId 更換成 cityName，這樣我們在查詢業務表的時候就不需要去 join 那一張 city 的字典表了。這樣的方式顯然是不符合我們資料庫設計的範式的，但是這樣的冗餘或許很有必要。
2、查詢某一個狀態值數據
業務表中有一個欄位 status 用來存儲提交和未提交，假設這張表中未提交的數據相對於提交的數據是很少的，當用戶查詢所有未提交的數據的時候，就需要在全部的數據，然後篩選出未同意的數據。如果這張業務表非常的龐大，那麼這樣的查詢的效率就非常的慢。
這個時候我們就可以把這張業務表中的未同意的數據冗餘到一張新表中，這樣用戶查詢未提交的數據的時候就可以直接在這張未提交的表中查詢，查詢速度提交很多。
E. 如何解決資料庫負載過大的問題
市面上存在兩種資料庫負載均衡的思路：1. 基於資料庫連接的負載均衡：例如總共有100個資料庫連接，50個連接登錄到資料庫機器A，另外50個連接登錄到資料庫機器B，這樣每個連接中接下來的所有請求全都是發往同一台資料庫機器的。 這種資料庫負載均衡的思路模擬了WEB上的負載均衡方法，但是由於WEB連接是短時間連接(連接建立後，獲取需要的HTML等資源後，連接馬上被關閉)，而資料庫連接是長時間連接( 連接建立後，可長時間保持，客戶可不停向資料庫發送SQL請求，資料庫做出回答，如此不斷循環直到連接被人為或因錯而斷開為止)，因此這種資料庫負載均衡思路存在著明顯的缺點：有可能會發生絕大部分的請求壓力都集中到某台資料庫機器上去，從而使得負載均衡效果失效。2.基於批處理請求的負載均衡：在建立資料庫連接的時候，會同時與每台資料庫伺服器建立連接，之後針對客戶端的每次請求，都會根據負載均衡演算法，獨立地選出某個資料庫節點來執行這個請求。此種思路符合資料庫長時間連接的特徵，不存在上面所述的基於連接的負載均衡方法的缺點。市面上的負載均衡廠商，既有基於連接的，也有基於批處理請求的，用戶需仔細辨別才能找到自己想要的合適產品。
F. 資料庫系統應如何負載平衡
在做資料庫多台並行前，要先確定數據一致性需要多高，如果可以容忍有時間差的同步，可以考慮用Big Table架構的資料庫來進行處理，否則就是加快取吧，並且盡量把資料庫讀/寫的任務分散來做。
理論上講，合理的作法應該是要組成Database Cluster才對。在Cluster的環境中，Database主機可以有很多台，但是大家的後端都接到同一個外部存儲器（通常是SAN），所有主機都寫入同一個存儲器內的一個資料庫而已，也因為只有一個存儲器、一個資料庫，所以主機之間沒有同步的需要。
負載平衡設備是不能解決資料庫負載過重的問題，但Databse Server性能不足的原因很多，應詳細探究為何性能不足，架Database Cluster能解決部分問題，但不一定能帶來太大性能上的改進。
拆Table結構是一個方法，通常是用在數據量特大的Table才建議，但用這種方式，程序開發人員一定會很痛苦，如果真要採取這種架構，建議程序架構要多一層數據存取層，商業物件不能直接下SQL存取資料庫數據，要通過數據存取層元件來存取資料庫數據，才能避免程序工程師的人為錯誤。
建議是先分析資料庫性能瓶頸，再來決定架構。根據經驗，Disk I/O是最大的問題，而造成Disk I/O的原因，通常是Index沒設好，或是程序設計師撰寫的SQL指令，沒考慮到數據增長後的性能問題。
G. oracle資料庫很慢 cpu負載很高 看到的等待事件是cursor:mutex s,要怎麼辦啊
cursor: mutex * events等待事件
cursor: mutex * events等待事件用於Cursor Parent 和 Cursor stats類型的操作：
『Cursor: Mutex S』 ， 某個進程以SHRD S mode申請一個Mutex， 而該Mutex要麼被其他進程已EXCL X mode所持有，要麼其他進程正在更新mutex 上的Ref Count。
相關類型的操作一般是檢測父游標或者CURSOR統計信息數據， 此外查詢V$SQLSTATS也會造成CURSOR statistics被查詢
如果自己搞不定可以找ASKMACLEAN專業ORACLE資料庫修復團隊成員幫您恢復!
H. MySQL資料庫負載很高連接數很多怎麼處理
您好，很高興為您解答。
第一先限制Innodb的並發處理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看機器壓力,如果
非常大,先改成16讓機器的壓力下來,然後慢慢增達,適應自已的業務.
處理方法: set global innodb_thread_concurrency=16;
第二: 對於連接數已經超過600或是更多的情況,可以考慮適當的限制一下連接數,讓前端報一下錯,也別讓DB掛了.
DB在了,總是可以用來載入一下數據,當數據載入到了nosql里了,慢慢的DB壓力也會降下來的.
限制單用戶連接數在500以下. 如:
set global max_user_connections=500;
(MySQL隨著連接數的增加性能會是下降的,這也是thread_pool出現的原因)
另外對於有的監控程序會讀取information_schema下面的表的程序可以考慮關閉下面的參數
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0;
這個參數主要防止對讀取information_schema時造成大量讀取磁碟進行信息統計(如果慢查詢中出現關於information_schema中表時,也可以考慮禁用該參數)
處理依據:
當學校的一個食堂一分鍾只能為兩個打飯, 忽然來了100個時人來打飯,又沒排隊, 不出會現了打飯的師傅要用點時間
去選擇為那個用戶服務了, 人越多,場面就越亂, 難免出現用戶大吼該他的場面, 最後有可能就出現不是打飯了,而時之間相互
打架了,打飯的師傅也將收到同時有90個以上的Server too busy. 如果能排一下隊.最多也就50分鍾能處理完了.
以前辦法,應該可以讓MySQLD不會掛掉.如果業務支撐受到限制,還是想辦法處理一下.
如若滿意，請點擊右側【採納答案】，如若還有問題，請點擊【追問】
希望我的回答對您有所幫助，望採納！
~ O(∩_∩)O~
I. 如何優化因 MYSQL 讀寫頻繁，負載過高導致的CPU高佔用率
診斷思路
mpstat -P ALL 1，查看cpu使用情況，主要消耗在sys即os系統調用上