mysql數據庫性能影響因素,影響數據庫性能的因素

本文目錄一覽：

• 1、哪些因素會對mysql數據庫服務器性能造成影響
• 2、影響數據庫性能的主要因素有哪些？
• 3、哪些因素影響了數據庫性能
• 4、超詳細MySQL數據庫優化

哪些因素會對mysql數據庫服務器性能造成影響

網絡寬帶也會有所影響。

網絡是數據庫基礎架構的主要部分。但是，通常性能基準測試是在本地計算機上完成的，客戶端和服務器並置在一起。這樣做是為了簡化結構並排除一個以上的變量（網絡部分），但是我們也忽略了網絡對性能的影響。對於像 MySQL Group Replication 這樣的產品集群來說，網絡更為重要。在這篇文章中，我將介紹網絡設置。這些都是簡單而微不足道的，但卻是讓我們更了解複雜網絡設置效果的基石。

安裝我將使用兩台裸機服務器，通過專用的 10Gb 網絡連接。我將通過使用 ethtool-s eth1 speed1000duplex full autoneg off 命令更改網絡接口速度來模擬 1Gb 網絡。

我將運行一個簡單的基準：sysbench oltp_read_only –mysql-ssl=on –mysql-host=172.16.0.1 –tables=20 –table-size=10000000 –mysql-user=sbtest –mysql-password=sbtest –threads=$i –time=300 –report-interval=1 –rand-type=pareto

運行時線程數從 1 到 2048 不等。所有數據都適合內存 -innodb_buffer_pool_size 足夠大。因此工作負載在內存中佔用大量 CPU：沒有 IO 開銷。操作系統：Ubuntu 16.04

N1 基準-網絡帶寬在第一個實驗中，我將比較 1Gb 網絡和 10Gb 網絡。顯然，1Gb 網絡性能是這裡的瓶頸，如果我們遷移到 10Gb 網絡，我們可以顯着改善我們的結果。要查看 1Gb 網絡是瓶頸，我們可以檢查 PMM（percona 的數據庫監控管理開源工具） 中的網絡流量圖表：

我們可以看到我們的吞吐量達到了 116 MiB/s（或 928 Mb/s)，這非常接近網絡帶寬。但是，如果我們的網絡基礎設施僅限於 1Gb，我們可以做些什麼？

N2 基準-協議壓縮MySQL 協議中有一個功能，您可以看到客戶端和服務器之間的網絡交換壓縮：–mysql-compression=on。讓我們看看它將如何影響我們的結果。

這是一個有趣的結果。當我們使用所有可用的網絡帶寬時，協議壓縮實際上有助於改善結果。

但是 10Gb 網絡不是這種情況。壓縮/解壓縮所需的 CPU 資源是一個限制因素，通過壓縮，吞吐量實際上只達到我們沒有壓縮的一半。現在讓我們談談協議加密，以及如何使用 SSL 影響我們的結果。

N3基準-網絡加密

對於 1Gb 網絡，SSL 加密顯示了一些損失 – 單線程約為 10％ – 但是否則我們再次達到帶寬限制。我們還看到了大量線程的可擴展性，這在 10Gb 網絡案例中更為明顯。使用 10Gb 時，SSL 協議在 32 個線程後不會擴展。實際上，它似乎是 MySQL 目前使用的 OpenSSL 1.0 中的可伸縮性問題。在我們的實驗中，我們看到 OpenSSL 1.1.1 提供了更好的可伸縮性，但是您需要從鏈接到OpenSSL 1.1.1 的源代碼中獲得特殊的 MySQL 構建才能實現這一點。我沒有在這裡展示它們，因為我們沒有生產二進制文件。

結論

1. 網絡性能和利用率將影響一般應用程序吞吐量。

2. 檢查您是否達到了網絡帶寬限制。

3. 如果受到網絡帶寬的限制，協議壓縮可以改善結果，但如果不是，則可能會使事情變得更糟。

4. SSL 加密在線程數量較少的情況下會有一些損失（約10％），但對於高並發工作負載，它不會擴展。

影響數據庫性能的主要因素有哪些？

1、1、調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE數據庫的分區功能，對於經常訪問的數據庫表是否需要建立索引等。

2、2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的數據庫資源是不同的。

3、3、調整數據庫SQL語句。應用程序的執行最終將歸結為數據庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE數據庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。

4、4、調整服務器內存分配。內存分配是在信息系統運行過程中優化配置的，數據庫管理員可以根據數據庫運行狀況調整數據庫系統全局區（SGA區）的數據緩衝區、日誌緩衝區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。

5、5、調整硬盤I/O，這一步是在信息系統開發之前完成的。數據庫管理員可以將組成同一個表空間的數據文件放在不同的硬盤上，做到硬盤之間I/O負載均衡。

6、6、調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE數據庫，可以調整UNIX數據緩衝池的大小，每個進程所能使用的內存大小等參數。

實際上，上述數據庫優化措施之間是相互聯繫的。ORACLE數據庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要數據庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響數據庫性能的主要原因所在。另外，良好的數據庫管理工具對於優化數據庫性能也是很重要的。

ORACLE數據庫性能優化工具

常用的數據庫性能優化工具有：

1、1、ORACLE數據庫在線數據字典，ORACLE在線數據字典能夠反映出ORACLE動態運行情況，對於調整數據庫性能是很有幫助的。

2、2、操作系統工具，例如UNIX操作系統的vmstat，iostat等命令可以查看到系統系統級內存和硬盤I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現在什麼地方有時候很有用。

3、3、SQL語言跟蹤工具（SQL TRACE FACILITY），SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整實例，使用SQL語句跟蹤文件調整應用程序性能。SQL語言跟蹤工具將結果輸出成一個操作系統的文件，管理員可以使用TKPROF工具查看這些文件。

4、4、ORACLE Enterprise Manager（OEM），這是一個圖形的用戶管理界面，用戶可以使用它方便地進行數據庫管理而不必記住複雜的ORACLE數據庫管理的命令。

5、5、EXPLAIN PLAN——SQL語言優化命令，使用這個命令可以幫助程序員寫出高效的SQL語言。

ORACLE數據庫的系統性能評估

信息系統的類型不同，需要關注的數據庫參數也是不同的。數據庫管理員需要根據自己的信息系統的類型着重考慮不同的數據庫參數。

1、1、在線事務處理信息系統（OLTP），這種類型的信息系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證數據庫的並發性、可靠性和最終用戶的速度，這類系統使用的ORACLE數據庫需要主要考慮下述參數：

l l 數據庫回滾段是否足夠？

l l 是否需要建立ORACLE數據庫索引、聚集、散列？

l l 系統全局區（SGA）大小是否足夠？

l l SQL語句是否高效？

2、2、數據倉庫系統（Data Warehousing），這種信息系統的主要任務是從ORACLE的海量數據中進行查詢，得到數據之間的某些規律。數據庫管理員需要為這種類型的ORACLE數據庫着重考慮下述參數：

l l 是否採用B*-索引或者bitmap索引？

l l 是否採用並行SQL查詢以提高查詢效率？

l l 是否採用PL/SQL函數編寫存儲過程？

l l 有必要的話，需要建立並行數據庫提高數據庫的查詢效率

SQL語句的調整原則

SQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程序員可以使用EXPLAIN PLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程序員寫SQL語句需要滿足考慮如下規則：

1、1、盡量使用索引。試比較下面兩條SQL語句：

語句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN

(SELECT deptno FROM emp);

語句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS

(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno);

這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分數據掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。

2、2、選擇聯合查詢的聯合次序。考慮下面的例子：

SELECT stuff FROM taba a, tabb b, tabc c

WHERE a.acol between :alow and :ahigh

AND b.bcol between :blow and :bhigh

AND c.ccol between :clow and :chigh

AND a.key1 = b.key1

AMD a.key2 = c.key2;

這個SQL例子中，程序員首先需要選擇要查詢的主表，因為主表要進行整個表數據的掃描，所以主表應該數據量最小，所以例子中表A的acol列的範圍應該比表B和表C相應列的範圍小。

3、3、在子查詢中慎重使用IN或者NOT IN語句，使用where (NOT) exists的效果要好的多。

4、4、慎重使用視圖的聯合查詢，尤其是比較複雜的視圖之間的聯合查詢。一般對視圖的查詢最好都分解為對數據表的直接查詢效果要好一些。

5、5、可以在參數文件中設置SHARED_POOL_RESERVED_SIZE參數，這個參數在SGA共享池中保留一個連續的內存空間，連續的內存空間有益於存放大的SQL程序包。

6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經常使用的存儲過程“釘”在SQL區中而不被換出內存，程序員對於經常使用並且佔用內存很多的存儲過程“釘”到內存中有利於提高最終用戶的響應時間。

CPU參數的調整

CPU是服務器的一項重要資源，服務器良好的工作狀態是在工作高峰時CPU的使用率在90％以上。如果空閑時間CPU使用率就在90％以上，說明服務器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明服務器CPU資源還比較富餘。

使用操作相同命令可以看到CPU的使用情況，一般UNIX操作系統的服務器，可以使用sar –u命令查看CPU的使用率，NT操作系統的服務器，可以使用NT的性能管理器來查看CPU的使用率。

數據庫管理員可以通過查看v$sysstat數據字典中“CPU used by this session”統計項得知ORACLE數據庫使用的CPU時間，查看“OS User level CPU time”統計項得知操作系統用戶態下的CPU時間，查看“OS System call CPU time”統計項得知操作系統系統態下的CPU時間，操作系統總的CPU時間就是用戶態和系統態時間之和，如果ORACLE數據庫使用的CPU時間占操作系統總的CPU時間90％以上，說明服務器CPU基本上被ORACLE數據庫使用着，這是合理，反之，說明服務器CPU被其它程序佔用過多，ORACLE數據庫無法得到更多的CPU時間。

數據庫管理員還可以通過查看v$sesstat數據字典來獲得當前連接ORACLE數據庫各個會話佔用的CPU時間，從而得知什麼會話耗用服務器CPU比較多。

出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖衝突都會引起CPU資源不足。

1、數據庫管理員可以執行下述語句來查看SQL語句的解析情況：

SELECT * FROM V$SYSSTAT

WHERE NAME IN

(‘parse time cpu’, ‘parse time elapsed’, ‘parse count (hard)’);

這裡parse time cpu是系統服務時間，parse time elapsed是響應時間，用戶等待時間

waite time = parse time elapsed – parse time cpu

由此可以得到用戶SQL語句平均解析等待時間＝waite time / parse count。這個平均等待時間應該接近於0，如果平均解析等待時間過長，數據庫管理員可以通過下述語句

SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA

ORDER BY PARSE_CALLS;

來發現是什麼SQL語句解析效率比較低。程序員可以優化這些語句，或者增加ORACLE參數SESSION_CACHED_CURSORS的值。

2、數據庫管理員還可以通過下述語句：

SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA;

查看低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。

3、3、數據庫管理員可以通過v$system_event數據字典中的“latch free”統計項查看ORACLE數據庫的衝突情況，如果沒有衝突的話，latch free查詢出來沒有結果。如果衝突太大的話，數據庫管理員可以降低spin_count參數值，來消除高的CPU使用率。

內存參數的調整

內存參數的調整主要是指ORACLE數據庫的系統全局區（SGA）的調整。SGA主要由三部分構成：共享池、數據緩衝區、日誌緩衝區。

1、 1、 共享池由兩部分構成：共享SQL區和數據字典緩衝區，共享SQL區是存放用戶SQL命令的區域，數據字典緩衝區存放數據庫運行的動態信息。數據庫管理員通過執行下述語句：

select (sum(pins – reloads)) / sum(pins) “Lib Cache” from v$librarycache;

來查看共享SQL區的使用率。這個使用率應該在90％以上，否則需要增加共享池的大小。數據庫管理員還可以執行下述語句：

select (sum(gets – getmisses – usage – fixed)) / sum(gets) “Row Cache” from v$rowcache;

查看數據字典緩衝區的使用率，這個使用率也應該在90％以上，否則需要增加共享池的大小。

2、 2、 數據緩衝區。數據庫管理員可以通過下述語句：

SELECT name, value FROM v$sysstat WHERE name IN (‘db block gets’, ‘consistent gets’,’physical reads’);

來查看數據庫數據緩衝區的使用情況。查詢出來的結果可以計算出來數據緩衝區的使用命中率＝1 – ( physical reads / (db block gets + consistent gets) )。

這個命中率應該在90％以上，否則需要增加數據緩衝區的大小。

3、 3、 日誌緩衝區。數據庫管理員可以通過執行下述語句：

select name,value from v$sysstat where name in (‘redo entries’,’redo log space requests’);查看日誌緩衝區的使用情況。查詢出的結果可以計算出日誌緩衝區的申請失敗率：

申請失敗率＝requests/entries，申請失敗率應該接近於0，否則說明日誌緩衝區開設太小，需要增加ORACLE數據庫的日誌緩衝區。

哪些因素影響了數據庫性能

網絡寬帶，磁盤IO，查詢速度都會影響到數據庫的性能。

    具體問題具體分析，舉例來說明為什麼磁盤IO成瓶頸數據庫的性能急速下降了。

   為什麼當磁盤IO成瓶頸之後, 數據庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼數據庫的性能有非常明顯的分界點，原因是什麼？

    相信大部分做數據庫運維的朋友，都遇到這種情況。 數據庫在前一天性能表現的相當穩定，數據庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，數據庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？

dba此時心中有無限的疑惑，到底是什麼原因呢? 磁盤IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是數據庫內部出問題？昨天不是還好好的嗎？

 當數據庫出現響應時間不穩定的時候，我們在操作系統上會看到磁盤的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 數據庫服務器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁盤的機器），對於在線交易的數據庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁盤讀IO跟寫IO所帶來的性能差距這麼大呢？

如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。

在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如異步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。

咱們先來提問題。 buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。

提問. 數據頁不在buffer bool 裡面該怎麼辦？

  回答：去讀文件，將文件中的數據頁加載到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁加載到buffer pool, 圖片中顯示

buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。

buf_read_page的代碼

 如果去讀文件，則需要等待物理讀IO的完成，如果此時IO沒有及時響應，則存在堵塞。這是一個同步讀的操作，如果不完成該線程無法繼續後續的步驟。因為需要的數據頁不再buffer 中，無法直接使用該數據頁，必須等待操作系統完成IO .

再接着上面的回答提問：

當第二會話線程執行sql的時候，也需要去訪問相同的數據頁，它是等待上面的線程將這個數據頁讀入到緩存中，還是自己再發起一個讀磁盤的然後加載到buffer的請求呢？   代碼告訴我們，是前者，等待第一個請求該數據頁的線程讀入buffer pool。

試想一下，如果第一個請求該數據頁的線程因為磁盤IO瓶頸，遲遲沒有將物理數據頁讀入buffer pool, 這個時間區間拖得越長，則造成等待該數據塊的用戶線程就越多。對高並發的系統來說，將造成大量的等待。 等待數據頁讀入的函數是buf_wait_for_read，下面是該函數相關的棧。

通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。

再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。

由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁盤上加載到buffer pool中時，造成的延遲，是難以想象的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。

再回頭來看上面的問題，mysql數據庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在數據庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行異步寫盤，這個異步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，數據庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁盤上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。  當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁盤上讀取數據頁到buffer pool, 則數據庫的性能則開始下降，當出現大量的讀IO，數據庫的性能會非常差。

超詳細MySQL數據庫優化

數據庫優化一方面是找出系統的瓶頸,提高MySQL數據庫的整體性能,而另一方面需要合理的結構設計和參數調整,以提高用戶的相應速度,同時還要儘可能的節約系統資源,以便讓系統提供更大的負荷.

1. 優化一覽圖

2. 優化

筆者將優化分為了兩大類,軟優化和硬優化,軟優化一般是操作數據庫即可,而硬優化則是操作服務器硬件及參數設置.

2.1 軟優化

2.1.1 查詢語句優化

1.首先我們可以用EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執行信息.

2.例:

顯示:

其中會顯示索引和查詢數據讀取數據條數等信息.

2.1.2 優化子查詢

在MySQL中,盡量使用JOIN來代替子查詢.因為子查詢需要嵌套查詢,嵌套查詢時會建立一張臨時表,臨時表的建立和刪除都會有較大的系統開銷,而連接查詢不會創建臨時表,因此效率比嵌套子查詢高.

2.1.3 使用索引

索引是提高數據庫查詢速度最重要的方法之一,關於索引可以參高筆者MySQL數據庫索引一文,介紹比較詳細,此處記錄使用索引的三大注意事項:

2.1.4 分解表

對於字段較多的表,如果某些字段使用頻率較低,此時應當,將其分離出來從而形成新的表,

2.1.5 中間表

對於將大量連接查詢的表可以創建中間表,從而減少在查詢時造成的連接耗時.

2.1.6 增加冗餘字段

類似於創建中間表,增加冗餘也是為了減少連接查詢.

2.1.7 分析表,,檢查表,優化表

分析表主要是分析表中關鍵字的分布,檢查表主要是檢查表中是否存在錯誤,優化表主要是消除刪除或更新造成的表空間浪費.

1. 分析表: 使用 ANALYZE 關鍵字,如ANALYZE TABLE user;

2. 檢查表: 使用 CHECK關鍵字,如CHECK TABLE user [option]

option 只對MyISAM有效,共五個參數值:

3. 優化表:使用OPTIMIZE關鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

LOCAL|NO_WRITE_TO_BINLOG都是表示不寫入日誌.,優化表只對VARCHAR,BLOB和TEXT有效,通過OPTIMIZE TABLE語句可以消除文件碎片,在執行過程中會加上只讀鎖.

2.2 硬優化

2.2.1 硬件三件套

1.配置多核心和頻率高的cpu,多核心可以執行多個線程.

2.配置大內存,提高內存,即可提高緩存區容量,因此能減少磁盤I/O時間,從而提高響應速度.

3.配置高速磁盤或合理分布磁盤:高速磁盤提高I/O,分布磁盤能提高並行操作的能力.

2.2.2 優化數據庫參數

優化數據庫參數可以提高資源利用率,從而提高MySQL服務器性能.MySQL服務的配置參數都在my.cnf或my.ini,下面列出性能影響較大的幾個參數.

2.2.3 分庫分表

因為數據庫壓力過大，首先一個問題就是高峰期系統性能可能會降低，因為數據庫負載過高對性能會有影響。另外一個，壓力過大把你的數據庫給搞掛了怎麼辦？所以此時你必須得對系統做分庫分表 + 讀寫分離，也就是把一個庫拆分為多個庫，部署在多個數據庫服務上，這時作為主庫承載寫入請求。然後每個主庫都掛載至少一個從庫，由從庫來承載讀請求。

2.2.4 緩存集群

如果用戶量越來越大，此時你可以不停的加機器，比如說系統層面不停加機器，就可以承載更高的並發請求。然後數據庫層面如果寫入並發越來越高，就擴容加數據庫服務器，通過分庫分表是可以支持擴容機器的，如果數據庫層面的讀並發越來越高，就擴容加更多的從庫。但是這裡有一個很大的問題：數據庫其實本身不是用來承載高並發請求的，所以通常來說，數據庫單機每秒承載的並發就在幾千的數量級，而且數據庫使用的機器都是比較高配置，比較昂貴的機器，成本很高。如果你就是簡單的不停的加機器，其實是不對的。所以在高並發架構里通常都有緩存這個環節，緩存系統的設計就是為了承載高並發而生。所以單機承載的並發量都在每秒幾萬，甚至每秒數十萬，對高並發的承載能力比數據庫系統要高出一到兩個數量級。所以你完全可以根據系統的業務特性，對那種寫少讀多的請求，引入緩存集群。具體來說，就是在寫數據庫的時候同時寫一份數據到緩存集群里，然後用緩存集群來承載大部分的讀請求。這樣的話，通過緩存集群，就可以用更少的機器資源承載更高的並發。

一個完整而複雜的高並發系統架構中，一定會包含：各種複雜的自研基礎架構系統。各種精妙的架構設計.因此一篇小文頂多具有拋磚引玉的效果,但是數據庫優化的思想差不多就這些了.