建站
咨詢
售后
建站咨詢
新聞中心
隨著互聯(lián)網(wǎng)的不斷發(fā)展，數(shù)據(jù)庫(kù)已經(jīng)成為了現(xiàn)代企業(yè)中不可或缺的一部分。然而，隨著業(yè)務(wù)量和數(shù)據(jù)量的不斷增加，很多企業(yè)都經(jīng)歷過數(shù)據(jù)庫(kù)負(fù)荷過大的問題，導(dǎo)致服務(wù)質(zhì)量下降和系統(tǒng)崩潰等嚴(yán)重后果。在這篇文章中，我們將討論一下如何解決數(shù)據(jù)庫(kù)負(fù)荷過大問題。
我們注重客戶提出的每個(gè)要求，我們充分考慮每一個(gè)細(xì)節(jié)，我們積極的做好網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作服務(wù)，我們努力開拓更好的視野，通過不懈的努力，創(chuàng)新互聯(lián)贏得了業(yè)內(nèi)的良好聲譽(yù)，這一切，也不斷的激勵(lì)著我們更好的服務(wù)客戶。 主要業(yè)務(wù)：網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)站設(shè)計(jì),小程序制作,網(wǎng)站開發(fā),技術(shù)開發(fā)實(shí)力，DIV+CSS，PHP及ASP，ASP.Net，SQL數(shù)據(jù)庫(kù)的技術(shù)開發(fā)工程師。
1. 數(shù)據(jù)庫(kù)優(yōu)化
數(shù)據(jù)庫(kù)優(yōu)化是解決數(shù)據(jù)庫(kù)負(fù)荷過大的首要方法。通過對(duì)數(shù)據(jù)庫(kù)的各項(xiàng)參數(shù)進(jìn)行調(diào)整和優(yōu)化，能夠有效地提升數(shù)據(jù)庫(kù)的性能和穩(wěn)定性，降低系統(tǒng)的負(fù)荷。常見的數(shù)據(jù)庫(kù)優(yōu)化包括以下幾個(gè)方面：
（1）參數(shù)調(diào)整
數(shù)據(jù)庫(kù)的各項(xiàng)參數(shù)設(shè)置對(duì)性能的影響非常大，需要根據(jù)實(shí)際情況進(jìn)行調(diào)整。例如增加緩存、擴(kuò)大連接池、調(diào)整垃圾回收等方式可以有效地提升數(shù)據(jù)庫(kù)性能。
（2）索引優(yōu)化
索引是數(shù)據(jù)庫(kù)的基礎(chǔ)結(jié)構(gòu)，能夠提升查詢效率、縮短查詢時(shí)間。合理地設(shè)置和優(yōu)化索引能夠有效地降低數(shù)據(jù)庫(kù)的負(fù)荷。
（3）分表分庫(kù)
隨著數(shù)據(jù)量的增加，單庫(kù)單表模式不適用。適時(shí)地進(jìn)行分表分庫(kù)，可以減少單節(jié)點(diǎn)的負(fù)荷，提升數(shù)據(jù)庫(kù)查詢效率。例如，將訂單數(shù)據(jù)按照時(shí)間進(jìn)行分表，能夠有效地降低查詢的時(shí)間和負(fù)載。
2. 負(fù)載均衡
當(dāng)單個(gè)節(jié)點(diǎn)無(wú)法滿足業(yè)務(wù)需求時(shí)，可以通過負(fù)載均衡的方式將請(qǐng)求分發(fā)到多個(gè)節(jié)點(diǎn)上，使得每個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)負(fù)載均衡，提高系統(tǒng)的可用性和負(fù)載能力。常見的負(fù)載均衡方式包括以下幾個(gè)：
（1）物理負(fù)載均衡
物理負(fù)載均衡是指使用硬件設(shè)備對(duì)數(shù)據(jù)庫(kù)節(jié)點(diǎn)進(jìn)行分布和轉(zhuǎn)發(fā)，如使用負(fù)載均衡器來(lái)實(shí)現(xiàn)數(shù)據(jù)流的分發(fā)和負(fù)載均衡。這種方式能夠支持很高的并發(fā)請(qǐng)求和吞吐量，對(duì)于大規(guī)模的數(shù)據(jù)中心和企業(yè)級(jí)應(yīng)用是非常重要的。
（2）軟件負(fù)載均衡
軟件負(fù)載均衡是指使用軟件組件來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)節(jié)點(diǎn)的分發(fā)和轉(zhuǎn)發(fā)，如使用Nginx或HAProxy等軟件實(shí)現(xiàn)負(fù)載均衡。這種方式對(duì)于小規(guī)模數(shù)據(jù)庫(kù)集群和中小型企業(yè)應(yīng)用非常適合，因?yàn)樗杀镜?、易于管理和維護(hù)。
3. 數(shù)據(jù)庫(kù)拆分
當(dāng)數(shù)據(jù)庫(kù)中的數(shù)據(jù)量越來(lái)越大時(shí)，可以將數(shù)據(jù)拆分到不同的節(jié)點(diǎn)上，從而將壓力分散到多個(gè)節(jié)點(diǎn)上，提高性能和擴(kuò)展性。拆分?jǐn)?shù)據(jù)庫(kù)可以分為垂直拆分和水平拆分兩種方式：
（1）垂直拆分
垂直拆分是指將單個(gè)數(shù)據(jù)庫(kù)中的數(shù)據(jù)按照不同的業(yè)務(wù)進(jìn)行劃分，將不同業(yè)務(wù)的數(shù)據(jù)存儲(chǔ)在不同的表中，如將訂單和商品信息存儲(chǔ)在不同的表中。這種方式能夠減少單表的數(shù)據(jù)量，提高查詢效率，但可能會(huì)增加查詢的復(fù)雜度和維護(hù)的難度。
（2）水平拆分
水平拆分是指將存儲(chǔ)在單個(gè)數(shù)據(jù)庫(kù)中的數(shù)據(jù)按照不同的分片規(guī)則進(jìn)行拆分，將不同分片的數(shù)據(jù)存儲(chǔ)到不同的節(jié)點(diǎn)上。例如，將數(shù)據(jù)按照用戶ID或訂單號(hào)等唯一標(biāo)識(shí)進(jìn)行分片，將不同分片的數(shù)據(jù)存儲(chǔ)在不同的數(shù)據(jù)庫(kù)或服務(wù)器上。這種方式能夠支持更大的數(shù)據(jù)量和更高的并發(fā)請(qǐng)求，并且能夠提高擴(kuò)展性和可用性。
在處理數(shù)據(jù)庫(kù)負(fù)荷過大問題時(shí)，需要根據(jù)實(shí)際情況選擇不同的解決方案。通過數(shù)據(jù)庫(kù)優(yōu)化、負(fù)載均衡和數(shù)據(jù)庫(kù)拆分等不同方式，能夠有效地提高數(shù)據(jù)庫(kù)的性能和擴(kuò)展性，提高系統(tǒng)的可用性和穩(wěn)定性，為企業(yè)的業(yè)務(wù)發(fā)展提供更加可靠的數(shù)據(jù)支持。
相關(guān)問題拓展閱讀：
- MSSQL數(shù)據(jù)庫(kù)占用內(nèi)存過大造成服務(wù)器死機(jī)問題的解決方法
- 怎樣給訪問量過大的mysql數(shù)據(jù)庫(kù)減壓
MSSQL數(shù)據(jù)庫(kù)占用內(nèi)存過大造成服務(wù)器死機(jī)問題的解決方法
使用MSSQL的站長(zhǎng)朋友都會(huì)被MSSQL數(shù)據(jù)庫(kù)吃內(nèi)存的能力佩服得五體投地 一個(gè)小小的網(wǎng)站 運(yùn)行若干天之后 MSSQL就會(huì)把服務(wù)器上所有的內(nèi)存都吃光 此時(shí)你不得不重新啟動(dòng)一下服務(wù)器或MSSQL來(lái)釋放內(nèi)存 有人認(rèn)為是MSSQL有內(nèi)存泄露問題 其實(shí)不然 微軟給我們了明確說明:
在您啟動(dòng) SQL Server 之后 SQL Server 內(nèi)存使用量將會(huì)持續(xù)穩(wěn)定上升 即使當(dāng)服務(wù)器上活動(dòng)很少時(shí)也不會(huì)下降 另外 任務(wù)管理器和性能監(jiān)視器將顯示計(jì)算機(jī)上可用的物理內(nèi)存穩(wěn)定下降 直到可用內(nèi)存降到 至 MB 為止
僅僅出現(xiàn)這種狀態(tài)不表示內(nèi)存泄漏 此行為是正常的 并且是 SQL Server 緩沖池的預(yù)期行為
默認(rèn)情況下 SQL Server 根據(jù)操作系統(tǒng)報(bào)告的物理內(nèi)存加載動(dòng)態(tài)增大和收縮其緩沖池(緩存)的大小 只要有足夠的內(nèi)存可用于防止內(nèi)存頁(yè)面交換(在 至 MB 之間) SQL Server 緩沖池就會(huì)繼續(xù)增大 像在與 SQL Server 分配內(nèi)存位于相同計(jì)算機(jī)上的其他進(jìn)程一樣 SQL Server 緩沖區(qū)管理器將在需要的時(shí)候釋放內(nèi)存 SQL Server 每秒可以釋放和獲取幾兆字節(jié)的內(nèi)存 從而使它可以快速適應(yīng)內(nèi)存分配變化
更多信息
您可以通過服務(wù)器內(nèi)存最小值和服務(wù)器內(nèi)存更大值配置選項(xiàng)設(shè)置 SQL Server 數(shù)據(jù)庫(kù)引擎使用的內(nèi)存(緩沖池)量的上下限 在設(shè)置服務(wù)器內(nèi)存最小值和服務(wù)器內(nèi)存更大值選項(xiàng)之前 請(qǐng)查閱以下 Microsoft 知識(shí)庫(kù)文章中標(biāo)題為”內(nèi)存”一節(jié)中的參考信息
HOW TO Determine Proper SQL Server Configuration Settings(確定正確的 SQL Server 配置設(shè)置)
請(qǐng)注意 服務(wù)器內(nèi)存更大值選項(xiàng)只限制 SQL Server 緩沖池的大小 服務(wù)器內(nèi)存更大值選項(xiàng)不限制剩余的未保留內(nèi)存區(qū)域 SQL Server 準(zhǔn)備將該區(qū)域分配給其他組件 例如擴(kuò)展存儲(chǔ)過程 對(duì)象 以及非共享 DLL EXE 和 MAPI 組件 由于前面的分配 SQL Server 專用字節(jié)超過服務(wù)器內(nèi)存更大值配置是很正常的 有關(guān)此未保留內(nèi)存區(qū)域中分配的其他信息 請(qǐng)單擊下面的文章編號(hào) 以查看 Microsoft 知識(shí)庫(kù)中相應(yīng)的文章
PRB 在使用大量數(shù)據(jù)庫(kù)時(shí)可能沒有足夠的虛擬內(nèi)存
參考
SQL Server 聯(lián)機(jī)圖書;主題 “服務(wù)器內(nèi)存最小值和更大值的影響”;”內(nèi)存體系結(jié)構(gòu)”;”服務(wù)器內(nèi)存選項(xiàng)”;”SQL Server 內(nèi)存池”
下面我們就來(lái)實(shí)戰(zhàn)如何限制MSSQL內(nèi)存使用:
之一步:打開企業(yè)管理雙擊進(jìn)入要修改的MSSQL
第二步:在左側(cè)MSSQL上點(diǎn)擊右鍵 選擇屬性 彈出SQL Server屬性(配置)對(duì)話框
第三步:點(diǎn)擊內(nèi)存選項(xiàng)卡
在這里 你會(huì)看到MSSQL默認(rèn)設(shè)置為使用更大內(nèi)存 也就是你所有的內(nèi)存 根據(jù)你的需要 設(shè)置它的更大值吧
lishixinzhi/Article/program/MySQL/202311/29533
怎樣給訪問量過大的mysql數(shù)據(jù)庫(kù)減壓
以MySQL為例，碎片的存在十分影響性能
MySQL 的碎片是 MySQL 運(yùn)維過程中比較常見的問題，碎片的存在十分影響數(shù)據(jù)庫(kù)的性能，本文將對(duì) MySQL 碎片進(jìn)行一次講解。
判斷方法：
MySQL 的碎片是否產(chǎn)生，通過查看
show table status from table_nameG;
這個(gè)命令中 Data_free 字段，如果該字段不為 0，則產(chǎn)生了數(shù)據(jù)碎片。
產(chǎn)生的原因：
1. 經(jīng)常進(jìn)行 delete 操作
經(jīng)常進(jìn)行 delete 操作，產(chǎn)生空白空間，如果進(jìn)行新的插入操作，MySQL將嘗試?yán)眠@些留空的區(qū)域，御簡(jiǎn)但仍然無(wú)法將其徹底占用，久而久之就產(chǎn)生了碎片；
演示：
創(chuàng)建一張表，往里面插入數(shù)據(jù)，進(jìn)行一個(gè)帶有 where 條件或者 limit 的 delete 操作，刪除前后對(duì)比鎮(zhèn)凱褲一下 Data_free 的變化。
刪除前：
刪除后：
Data_free 不為 0，說明有碎孫枝片；
2. update 更新
update 更新可變長(zhǎng)度的字段(例如 varchar 類型)，將長(zhǎng)的字符串更新成短的。之前存儲(chǔ)的內(nèi)容長(zhǎng)，后來(lái)存儲(chǔ)是短的，即使后來(lái)插入新數(shù)據(jù)，那么有一些空白區(qū)域還是沒能有效利用的。
演示：
創(chuàng)建一張表，往里面插入一條數(shù)據(jù)，進(jìn)行一個(gè) update 操作，前后對(duì)比一下 Data_free 的變化。
CREATE TABLE `t1` ( `k` varchar(3000) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
更新語(yǔ)句：update t1 set k=’aaa’;
更新前長(zhǎng)度：223 Data_free：0
更新后長(zhǎng)度：3 Data_free：204
Data_free 不為 0，說明有碎片；
產(chǎn)生影響：
1. 由于碎片空間是不連續(xù)的，導(dǎo)致這些空間不能充分被利用；
2. 由于碎片的存在，導(dǎo)致數(shù)據(jù)庫(kù)的磁盤 I/O 操作變成離散隨機(jī)讀寫，加重了磁盤 I/O 的負(fù)擔(dān)。
清理辦法：
MyISAM：optimize table 表名；（OPTIMIZE 可以整理數(shù)據(jù)文件,并重排索引）
Innodb：
1. ALTER TABLE tablename ENGINE=InnoDB；(重建表存儲(chǔ)引擎，重新組織數(shù)據(jù))
2. 進(jìn)行一次數(shù)據(jù)的導(dǎo)入導(dǎo)出
碎片清理的性能對(duì)比：
引用我之前一個(gè)生產(chǎn)庫(kù)的數(shù)據(jù)，對(duì)比一下清理前后的差異。
SQL執(zhí)行速度：
select count(*) from test.twitter_11;
修改前：1 row in set (7.37 sec)
修改后：1 row in set (1.28 sec)
結(jié)論：
通過對(duì)比，可以看到碎片清理前后，節(jié)省了很多空間，SQL執(zhí)行效率更快。所以，在日常運(yùn)維工作中，應(yīng)對(duì)碎片進(jìn)行定期清理，保證數(shù)據(jù)庫(kù)有穩(wěn)定的性能。
單機(jī)MySQL數(shù)據(jù)庫(kù)的優(yōu)化
一、服務(wù)器硬件對(duì)MySQL性能的影響
①磁盤尋道能力（磁盤I/O），我們現(xiàn)在上的都是SAS15000轉(zhuǎn)的硬盤。MySQL每秒鐘都在進(jìn)行大量、復(fù)雜的查詢操作，對(duì)磁盤的讀寫量可想而知。
所以，通常認(rèn)為磁盤I/O是制約MySQL性能的更大因素之一，對(duì)于日均訪
問量在100萬(wàn)PV以上的Discuz!論壇，由于磁盤I/O的制約，MySQL的性能會(huì)非常低下！解決這一制約因素可以考慮以下幾種解決方案：
使用RAID1+0磁盤陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁盤陣列上的效率不碰舉會(huì)像你期待的那樣快。
②CPU 對(duì)于MySQL應(yīng)用，推薦使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我現(xiàn)在比較喜歡DELL R710，也在用其作Linuxakg 虛擬化應(yīng)用；
③物理內(nèi)存對(duì)于一臺(tái)使用MySQL的Database Server來(lái)說，服務(wù)器內(nèi)存建高吵絕議不要小于2GB，推薦使用4GB以上的物理內(nèi)存，不過內(nèi)存對(duì)于現(xiàn)在的服務(wù)器而言可以說是一個(gè)可以忽略的問題，工作中遇到高端服務(wù)器基本上內(nèi)存都超過了32G。
我們工作中用得比較多的數(shù)據(jù)庫(kù)服務(wù)器是HP DL580G5和DELL R710，穩(wěn)定性和性能都不錯(cuò)；特別是DELL R710，我發(fā)現(xiàn)許多同行都是采用它作數(shù)據(jù)庫(kù)的服務(wù)器，所以重點(diǎn)推薦下。
二、MySQL的線上安裝我建議采取編譯安裝的方法，這樣性能上有較大提升，服務(wù)器系統(tǒng)我建議用64bit的Centos5.5，源碼包的編譯參數(shù)會(huì)默
認(rèn)以Debgu模式生成二進(jìn)制代碼，而Debug模式給MySQL帶來(lái)的性能損失是比較大的，所以當(dāng)我們編譯準(zhǔn)備安裝的產(chǎn)品代碼時(shí)，一定不要忘記使用“—
without-debug”參數(shù)禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二
個(gè)編譯參數(shù)設(shè)置為—all-static的話，可以告訴編譯器以靜態(tài)方式編譯和編譯結(jié)果代碼得到更高的性能。使用靜態(tài)編譯和使用動(dòng)態(tài)編譯的代碼相比，性能
差距可能會(huì)達(dá)到5%至10%之多。我參考了簡(jiǎn)朝陽(yáng)先生的編譯參數(shù)，特列如下，供大家參考
./configure
–prefix=/usr/local/mysql –without-debug –without-bench
–enable-thread-safe-client –enable-assembler –enable-profiling
–with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static
–with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb
–with-csv-storage-engine –with-federated-storage-engine
–with-mysqld-user=mysql –without-我是怎么了ded-server
–with-server-suffix=-community
–with-unix-socket-path=/usr/local/mysql/sock/mysql.sock
三、MySQL自身因素當(dāng)解決了上述服務(wù)器硬件制約因素后，讓我們看看MySQL自身的優(yōu)化是如何操作的。對(duì) MySQL自身的優(yōu)化主要是對(duì)其配置文件my.cnf中的各項(xiàng)參數(shù)進(jìn)行優(yōu)化調(diào)整。下面我們戚姿介紹一些對(duì)性能影響較大的參數(shù)。
下面，我們根據(jù)以上硬件配置結(jié)合一份已經(jīng)優(yōu)化好的my.cnf進(jìn)行說明：
#vim /etc/my.cnf
以下只列出my.cnf文件中段落中的內(nèi)容，其他段落內(nèi)容對(duì)MySQL運(yùn)行性能影響甚微，因而姑且忽略。
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部鎖定，減少出錯(cuò)幾率增強(qiáng)穩(wěn)定性。
skip-name-resolve
#禁止MySQL對(duì)外部連接進(jìn)行DNS解析，使用這一選項(xiàng)可以消除MySQL進(jìn)行DNS解析的時(shí)間。但需要注意，如果開啟該選項(xiàng)，則所有遠(yuǎn)程主機(jī)連接授權(quán)都要使用IP地址方式，否則MySQL將無(wú)法正常處理連接請(qǐng)求！
back_log = 384
#back_log參數(shù)的值指出在MySQL暫時(shí)停止響應(yīng)新請(qǐng)求之前的短時(shí)間內(nèi)多少個(gè)請(qǐng)求可以被存在堆棧中。
如果系統(tǒng)在一個(gè)短時(shí)間內(nèi)有很多連接，則需要增大該參數(shù)的值，該參數(shù)值指定到來(lái)的TCP/IP連接的偵聽隊(duì)列的大小。不同的操作系統(tǒng)在這個(gè)隊(duì)列大小上有它自
己的限制。 試圖設(shè)定back_log高于你的操作系統(tǒng)的限制將是無(wú)效的。默認(rèn)值為50。對(duì)于Linux系統(tǒng)推薦設(shè)置為小于512的整數(shù)。
key_buffer_size = 384M
#key_buffer_size指定用于索引的緩沖區(qū)大小，增加它可得到更好的索引處理性能。對(duì)于內(nèi)存在4GB左右的服務(wù)器該參數(shù)可設(shè)置為256M或384M。注意：該參數(shù)值設(shè)置的過大反而會(huì)是服務(wù)器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 614K
sort_buffer_size = 6M
#查詢排序時(shí)所能使用的緩沖區(qū)大小。注意：該參數(shù)對(duì)應(yīng)的分配內(nèi)存是每連接獨(dú)占，如果有100個(gè)連接，那么實(shí)際分配的總共排序緩沖區(qū)大小為100 × 6 ＝ 600MB。所以，對(duì)于內(nèi)存在4GB左右的服務(wù)器推薦設(shè)置為6-8M。
read_buffer_size = 4M
#讀查詢操作所能使用的緩沖區(qū)大小。和sort_buffer_size一樣，該參數(shù)對(duì)應(yīng)的分配內(nèi)存也是每連接獨(dú)享。
join_buffer_size = 8M
#聯(lián)合查詢操作所能使用的緩沖區(qū)大小，和sort_buffer_size一樣，該參數(shù)對(duì)應(yīng)的分配內(nèi)存也是每連接獨(dú)享。
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
#指定MySQL查詢緩沖區(qū)的大小?？梢酝ㄟ^在MySQL控制臺(tái)觀察，如果Qcache_lowmem_prunes的值非常大，則表明經(jīng)常出現(xiàn)緩沖不
夠
的情況；如果Qcache_hits的值非常大，則表明查詢緩沖使用非常頻繁，如果該值較小反而會(huì)影響效率，那么可以考慮不用查詢緩
沖；Qcache_free_blocks，如果該值非常大，則表明緩沖區(qū)中碎片很多。
tmp_table_size = 256M
max_connections = 768
#指定MySQL允許的更大連接進(jìn)程數(shù)。如果在訪問論壇時(shí)經(jīng)常出現(xiàn)Too Many Connections的錯(cuò)誤提 示，則需要增大該參數(shù)值。
max_connect_errors = 1000
wait_timeout = 10
#指定一個(gè)請(qǐng)求的更大連接時(shí)間，對(duì)于4GB左右內(nèi)存的服務(wù)器可以設(shè)置為5-10。
thread_concurrency = 8
#該參數(shù)取值為服務(wù)器邏輯CPU數(shù)量*2，在本例中，服務(wù)器有2顆物理CPU，而每顆物理CPU又支持H.T超線程，所以實(shí)際取值為4*2=8；這個(gè)目前也是雙四核主流服務(wù)器配置。
skip-networking
#開啟該選項(xiàng)可以徹底關(guān)閉MySQL的TCP/IP連接方式，如果WEB服務(wù)器是以遠(yuǎn)程連接的方式訪問MySQL數(shù)據(jù)庫(kù)服務(wù)器則不要開啟該選項(xiàng)！否則將無(wú)法正常連接！
table_cache=1024
#物理內(nèi)存越大，設(shè)置就越大。默認(rèn)為2402,調(diào)到更佳
innodb_additional_mem_pool_size=4M
#默認(rèn)為2M
innodb_flush_log_at_trx_commit=1
#設(shè)置為0就是等到innodb_log_buffer_size列隊(duì)滿后再統(tǒng)一儲(chǔ)存，默認(rèn)為1
innodb_log_buffer_size=2M
#默認(rèn)為1M
innodb_thread_concurrency=8
#你的服務(wù)器CPU有幾個(gè)就設(shè)置為幾，建議用默認(rèn)一般為8
key_buffer_size=256M
#默認(rèn)為218，調(diào)到128更佳
tmp_table_size=64M
#默認(rèn)為16M，調(diào)到64-256最掛
read_buffer_size=4M
#默認(rèn)為64K
read_rnd_buffer_size=16M
#默認(rèn)為256K
sort_buffer_size=32M
#默認(rèn)為256K
thread_cache_size=120
#默認(rèn)為60
query_cache_size=32M
※值得注意的是：
很多情況需要具體情況具體分析
一、如果Key_reads太大，則應(yīng)該把my.cnf中Key_buffer_size變大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。
很多時(shí)候我們發(fā)現(xiàn)，通過參數(shù)設(shè)置進(jìn)行性能優(yōu)化所帶來(lái)的性能提升，可能并不如許多人想象的那樣產(chǎn)生質(zhì)的飛躍，除非是之前的設(shè)置存在嚴(yán)重不合理的情況。我們
不能將性能調(diào)優(yōu)完全依托于通過DBA在數(shù)據(jù)庫(kù)上線后進(jìn)行的參數(shù)調(diào)整，而應(yīng)該在系統(tǒng)設(shè)計(jì)和開發(fā)階段就盡可能減少性能問題。
【51CTO獨(dú)家特稿】如果單MySQL的優(yōu)化始終還是頂不住壓力時(shí)，這個(gè)時(shí)候我們就必須考慮MySQL的高可用架構(gòu)（很多同學(xué)也愛說成是MySQL集群）了，目前可行的方案有：
一、MySQL Cluster
優(yōu)勢(shì)：可用性非常高，性能非常好。每份數(shù)據(jù)至少可在不同主機(jī)存一份拷貝，且冗余數(shù)據(jù)拷貝實(shí)時(shí)同步。但它的維護(hù)非常復(fù)雜，存在部分Bug，目前還不適合比較核心的線上系統(tǒng)，所以這個(gè)我不推薦。
二、DRBD磁盤網(wǎng)絡(luò)鏡像方案
優(yōu)勢(shì)：軟件功能強(qiáng)大，數(shù)據(jù)可在底層快設(shè)備級(jí)別跨物理主機(jī)鏡像，且可根據(jù)性能和可靠性要求配置不同級(jí)別的同步。IO操作保持順序，可滿足數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)一致
性的苛刻要求。但非分布式文件系統(tǒng)環(huán)境無(wú)法支持鏡像數(shù)據(jù)同時(shí)可見，性能和可靠性兩者相互矛盾，無(wú)法適用于性能和可靠性要求都比較苛刻的環(huán)境，維護(hù)成本高于
MySQL Replication。另外，DRBD也是官方推薦的可用于MySQL高可用方案之一，所以這個(gè)大家可根據(jù)實(shí)際環(huán)境來(lái)考慮是否部署。
三、MySQL Replication
在實(shí)際應(yīng)用場(chǎng)景中，MySQL
Replication是使用最為廣泛的一種提高系統(tǒng)擴(kuò)展性的設(shè)計(jì)手段。眾多的MySQL使用者通過Replication功能提升系統(tǒng)的擴(kuò)展性后，通過
簡(jiǎn)單的增加價(jià)格低廉的硬件設(shè)備成倍
甚至成數(shù)量級(jí)地提高了原有系統(tǒng)的性能，是廣大MySQL中低端使用者非常喜歡的功能之一，也是許多MySQL使用者選擇MySQL最為重要的原因。
比較常規(guī)的MySQL Replication架構(gòu)也有好幾種，這里分別簡(jiǎn)單說明下
MySQL Replication架構(gòu)一：常規(guī)復(fù)制架構(gòu)–Master-slaves，是由一個(gè)Master復(fù)制到一個(gè)或多個(gè)Salve的架構(gòu)模式，主要用于讀壓力大的應(yīng)用數(shù)據(jù)庫(kù)端廉價(jià)擴(kuò)展解決方案，讀寫分離，Master主要負(fù)責(zé)寫方面的壓力。
MySQL Replication架構(gòu)二：級(jí)聯(lián)復(fù)制架構(gòu)，即Master-Slaves-Slaves,這個(gè)也是為了防止Slaves的讀壓力過大，而配置一層二級(jí) Slaves，很容易解決Master端因?yàn)楦綄賡lave太多而成為瓶勁的風(fēng)險(xiǎn)。
MySQL Replication架構(gòu)三：Dual Master與級(jí)聯(lián)復(fù)制結(jié)合架構(gòu)，即Master-Master-Slaves，更大的好處是既可以避免主Master的寫操作受到Slave集群的復(fù)制帶來(lái)的影響，而且保證了主Master的單點(diǎn)故障。
以上就是比較常見的MySQL replication架構(gòu)方案，大家可根據(jù)自己公司的具體環(huán)境來(lái)設(shè)計(jì) ，Mysql 負(fù)載均衡可考慮用LVS或Haproxy來(lái)做，高可用HA軟件我推薦Heartbeat。
MySQL
Replication的不足：如果Master主機(jī)硬件故障無(wú)法恢復(fù)，則可能造成部分未傳送到slave端的數(shù)據(jù)丟失。所以大家應(yīng)該根據(jù)自己目前的網(wǎng)絡(luò)
規(guī)劃，選擇自己合理的Mysql架構(gòu)方案，跟自己的MySQL
數(shù)據(jù)庫(kù)負(fù)荷過大的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫(kù)負(fù)荷過大,如何解決數(shù)據(jù)庫(kù)負(fù)荷過大問題？,MSSQL數(shù)據(jù)庫(kù)占用內(nèi)存過大造成服務(wù)器死機(jī)問題的解決方法,怎樣給訪問量過大的mysql數(shù)據(jù)庫(kù)減壓的信息別忘了在本站進(jìn)行查找喔。
成都服務(wù)器租用選創(chuàng)新互聯(lián)，先試用再開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）提供簡(jiǎn)單好用，價(jià)格厚道的香港/美國(guó)云服務(wù)器和獨(dú)立服務(wù)器。物理服務(wù)器托管租用：四川成都、綿陽(yáng)、重慶、貴陽(yáng)機(jī)房服務(wù)器托管租用。
分享文章：如何解決數(shù)據(jù)庫(kù)負(fù)荷過大問題？ (數(shù)據(jù)庫(kù)負(fù)荷過大)
當(dāng)前地址：http://www.dlmjj.cn/article/cospdjj.html
