本文目錄一覽：
- 1、MySQL如何實現高可用？
- 2、mysql耗內存嗎？應該怎麼處理？
- 3、mysql數據庫最大連接數可以設置為多少
- 4、mysql數據庫最大能支持多少並發量
- 5、MySQL服務器數量大嗎
- 6、mysql數據庫服務器一般多少內存
MySQL如何實現高可用？
1. 概述
我們在考慮MySQL數據庫的高可用的架構時，主要要考慮如下幾方面：
關於對高可用的分級在這裡我們不做詳細的討論，這裡只討論常用高可用方案的優缺點以及高可用方案的選型。
2. 高可用方案
2.1. 主從或主主半同步複製
使用雙節點數據庫，搭建單向或者雙向的半同步複製。在5.7以後的版本中，由於lossless replication、logical多線程複製等一些列新特性的引入，使得MySQL原生半同步複製更加可靠。
常見架構如下：
通常會和proxy、keepalived等第三方軟件同時使用，即可以用來監控數據庫的 健康 ，又可以執行一系列管理命令。如果主庫發生故障，切換到備庫後仍然可以繼續使用數據庫。
優點：
缺點：
2.2. 半同步複製優化
半同步複製機制是可靠的。如果半同步複製一直是生效的，那麼便可以認為數據是一致的。但是由於網絡波動等一些客觀原因，導致半同步複製發生超時而切換為異步複製，那麼這時便不能保證數據的一致性。所以儘可能的保證半同步複製，便可提高數據的一致性。
該方案同樣使用雙節點架構，但是在原有半同複製的基礎上做了功能上的優化，使半同步複製的機制變得更加可靠。
可參考的優化方案如下：
半同步複製由於發生超時後，複製斷開，當再次建立起複制時，同時建立兩條通道，其中一條半同步複製通道從當前位置開始複製，保證從機知道當前主機執行的進度。另外一條異步複製通道開始追補從機落後的數據。當異步複製通道追趕到半同步複製的起始位置時，恢復半同步複製。
搭建兩條半同步複製通道，其中連接文件服務器的半同步通道正常情況下不啟用，當主從的半同步複製發生網絡問題退化後，啟動與文件服務器的半同步複製通道。當主從半同步複製恢復後，關閉與文件服務器的半同步複製通道。
優點：
缺點：
2.3. 高可用架構優化
將雙節點數據庫擴展到多節點數據庫，或者多節點數據庫集群。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的集群。
由於半同步複製，存在接收到一個從機的成功應答即認為半同步複製成功的特性，所以多從半同步複製的可靠性要優於單從半同步複製的可靠性。並且多節點同時宕機的幾率也要小於單節點宕機的幾率，所以多節點架構在一定程度上可以認為高可用性是好於雙節點架構。
但是由於數據庫數量較多，所以需要數據庫管理軟件來保證數據庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：
MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。
MHA Node運行在每台MySQL服務器上，主要作用是切換時處理二進制日誌，確保切換盡量少丟數據。
MHA也可以擴展到如下的多節點集群：
優點：
缺點：
Zookeeper使用分布式算法保證集群數據的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網絡分區現象的產生。
優點：
缺點：
2.4. 共享存儲
共享存儲實現了數據庫服務器和存儲設備的解耦，不同數據庫之間的數據同步不再依賴於MySQL的原生複製功能，而是通過磁盤數據同步的手段，來保證數據的一致性。
SAN的概念是允許存儲設備和處理器（服務器）之間建立直接的高速網絡（與LAN相比）連接，通過這種連接實現數據的集中式存儲。常用架構如下：
使用共享存儲時，MySQL服務器能夠正常掛載文件系統並操作，如果主庫發生宕機，備庫可以掛載相同的文件系統，保證主庫和備庫使用相同的數據。
優點：
缺點：
DRBD是一種基於軟件、基於網絡的塊複製存儲解決方案，主要用於對服務器之間的磁盤、分區、邏輯卷等進行數據鏡像，當用戶將數據寫入本地磁盤時，還會將數據發送到網絡中另一台主機的磁盤上，這樣的本地主機(主節點)與遠程主機(備節點)的數據就可以保證實時同步。常用架構如下：
當本地主機出現問題，遠程主機上還保留着一份相同的數據，可以繼續使用，保證了數據的安全。
DRBD是linux內核模塊實現的快級別的同步複製技術，可以與SAN達到相同的共享存儲效果。
優點：
缺點：
2.5. 分布式協議
分布式協議可以很好解決數據一致性問題。比較常見的方案如下：
MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗餘數據，實現數據庫的高可用性和數據一致性。
優點：
缺點：
基於Galera的MySQL高可用集群， 是多主數據同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構如下：
優點：
缺點：
Paxos 算法解決的問題是一個分布式系統如何就某個值（決議）達成一致。這個算法被認為是同類算法中最有效的。Paxos與MySQL相結合可以實現在分布式的MySQL數據的強一致性。常見架構如下：
優點：
缺點：
3. 總結
隨着人們對數據一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數據一致性的問題，如MySQL自身的優化、MySQL集群架構的優化、Paxos、Raft、2PC算法的引入等等。
而使用分布式算法用來解決MySQL數據庫數據一致性的問題的方法，也越來越被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規模使用。
隨着官方MySQL Group Replication的GA，使用分布式協議來解決數據一致性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，MySQL高可用問題可以被更好的解決。
分布式解決方案 tidb
多主 多備 master lvs做vip 讀寫分離中間件
mysql耗內存嗎？應該怎麼處理？
mysql耗內存嗎?很多人都說MySQL佔用了很大的虛擬內存，那麼這個問題應該怎麼解決呢?下面是我收集整理的一些方法，現在分享給大家!
解決mysql耗內存的具體方法一：
在分析的過程中發現最耗內存的是MySQL，其中近1GB的內存被它吞了，而且不在任務管理器體現出來。這個數據庫軟件是EMS要用到了，所以必須要運行。這個軟件在安裝的時候會根據機器的實際內存自動進行配置，PC機物理內存越多，它默認佔有的內存就越多，難怪3GB的內存被它給吞了近1GB。
優化方法：
1. 退出EMS clientserver
2. 在CMD里運行：net stop mysql
3. 找到MySQL\MySQL Server的安裝目錄，裡面有個my.ini文件，參考附件的配置對參數query_cache_size tmp_table_size myisam_sort_buffer_size key_buffer_size innodb_buffer_pool_size進行修改，注意不要改動innodb_log_file_size，修改前備份my.ini
4. 在CMD里運行：net start mysql，如果提示成功，則說明修改的參數沒有什麼問題，如果失敗，重新調整一下上面的參數
5. 找到EMS 安裝目錄runGUI.bat runServer.bat腳本，找到-Xmx700m，改為-Xmx256m，注意修改前備份這兩個文件，感謝Liping Sun提供幫助
6. 重新運行EMS
前後對比，對於3GB的PC，發現可以節省近1GB的內存。對於2GB的PC，也可以節省600-800MB。優化後發現EMS啟動稍微慢一些，但是其它的軟件運行速度提高了很多，不在經常出現卡機現象了。如果在運行過程中發現EMS特別慢的話，自己也可以適當放大上面提到的一些參數。
my.ini
# MySQL Server Instance Configuration File
# ———————————————————————-
# Generated by the MySQL Server Instance Configuration Wizard
#
#
# Installation Instructions
# ———————————————————————-
#
# On Linux you can copy this file to /etc/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options
# (@localstatedir@ for this installation) or to
# ~/.my.cnf to set user-specific options.
#
# On Windows you should keep this file in the installation directory
# of your server (e.g. C:\Program Files\MySQL\MySQL Server X.Y). To
# make sure the server reads the config file use the startup option
# “–defaults-file”.
#
# To run run the server from the command line, execute this in a
# command line shell, e.g.
# mysqld –defaults-file=”C:\Program Files\MySQL\MySQL Server X.Y\my.ini”
#
# To install the server as a Windows service manually, execute this in a
# command line shell, e.g.
# mysqld –install MySQLXY –defaults-file=”C:\Program Files\MySQL\MySQL Server X.Y\my.ini”
#
# And then execute this in a command line shell to start the server, e.g.
# net start MySQLXY
#
#
# Guildlines for editing this file
# ———————————————————————-
#
# In this file, you can use all long options that the program supports.
# If you want to know the options a program supports, start the program
# with the “–help” option.
#
# More detailed information about the individual options can also be
# found in the manual.
#
#
# CLIENT SECTION
# ———————————————————————-
#
# The following options will be read by MySQL client applications.
# Note that only client applications shipped by MySQL are guaranteed
# to read this section. If you want your own MySQL client program to
# honor these values, you need to specify it as an option during the
# MySQL client library initialization.
#
[client]
port=3306
[mysql]
default-character-set=utf8
# SERVER SECTION
# ———————————————————————-
#
# The following options will be read by the MySQL Server. Make sure that
# you have installed the server correctly (see above) so it reads this
# file.
#
[mysqld]
# The TCP/IP Port the MySQL Server will listen on
port=3306
#Path to installation directory. All paths are usually resolved relative to this.
basedir=”D:/Program Files/MySQL/MySQL Server 5.1/”
#Path to the database root
datadir=”C:/Documents and Settings/All Users/Application Data/MySQL/MySQL Server 5.1/Data/”
# The default character set that will be used when a new schema or table is
# created and no character set is defined
character-set-server=utf8
# The default storage engine that will be used when create new tables when
default-storage-engine=INNODB
# Set the SQL mode to strict
sql-mode=”STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”
# The maximum amount of concurrent sessions the MySQL server will
# allow. One of these connections will be reserved for a user with
# SUPER privileges to allow the administrator to login even if the
# connection limit has been reached.
max_connections=1510
# Query cache is used to cache SELECT results and later return them
# without actual executing the same query once again. Having the query
# cache enabled may result in significant speed improvements, if your
# have a lot of identical queries and rarely changing tables. See the
# “Qcache_lowmem_prunes” status variable to check if the current value
# is high enough for your load.
# Note: In case your tables change very often or if your queries are
# textually different every time, the query cache may result in a
# slowdown instead of a performance improvement.
query_cache_size=16M
# The number of open tables for all threads. Increasing this value
# increases the number of file descriptors that mysqld requires.
# Therefore you have to make sure to set the amount of open files
# allowed to at least 4096 in the variable “open-files-limit” in
# section [mysqld_safe]
table_cache=3020
# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to disk
# based table This limitation is for a single table. There can be many
# of them.
tmp_table_size=4M
# How many threads we should keep in a cache for reuse. When a client
# disconnects, the client’s threads are put in the cache if there aren’t
# more than thread_cache_size threads from before. This greatly reduces
# the amount of thread creations needed if you have a lot of new
# connections. (Normally this doesn’t give a notable performance
# improvement if you have a good thread implementation.)
thread_cache_size=64
#*** MyISAM Specific options
# The maximum size of the temporary file MySQL is allowed to use while
# recreating the index (during REPAIR, ALTER TABLE or LOAD DATA INFILE.
# If the file-size would be bigger than this, the index will be created
# through the key cache (which is slower).
myisam_max_sort_file_size=100G
# If the temporary file used for fast index creation would be bigger
# than using the key cache by the amount specified here, then prefer the
# key cache method. This is mainly used to force long character keys in
# large tables to use the slower key cache method to create the index.
myisam_sort_buffer_size=4M
# Size of the Key Buffer, used to cache index blocks for MyISAM tables.
# Do not set it larger than 30% of your available memory, as some memory
# is also required by the OS to cache rows. Even if you’re not using
# MyISAM tables, you should still set it to 8-64M as it will also be
# used for internal temporary disk tables.
key_buffer_size=16M
# Size of the buffer used for doing full table scans of MyISAM tables.
# Allocated per thread, if a full scan is needed.
read_buffer_size=64K
read_rnd_buffer_size=256K
# This buffer is allocated when MySQL needs to rebuild the index in
# REPAIR, OPTIMZE, ALTER table statements as well as in LOAD DATA INFILE
# into an empty table. It is allocated per thread so be careful with
# large settings.
sort_buffer_size=256K
#*** INNODB Specific options ***
# Use this option if you have a MySQL server with InnoDB support enabled
# but you do not plan to use it. This will save memory and disk space
# and speed up some things.
#skip-innodb
# Additional memory pool that is used by InnoDB to store metadata
# information. If InnoDB requires more memory for this purpose it will
# start to allocate it from the OS. As this is fast enough on most
# recent operating systems, you normally do not need to change this
# value. SHOW INNODB STATUS will display the current amount used.
innodb_additional_mem_pool_size=9M
# If set to 1, InnoDB will flush (fsync) the transaction logs to the
# disk at each commit, which offers full ACID behavior. If you are
# willing to compromise this safety, and you are running small
# transactions, you may set this to 0 or 2 to reduce disk I/O to the
# logs. Value 0 means that the log is only written to the log file and
# the log file flushed to disk approximately once per second. Value 2
# means the log is written to the log file at each commit, but the log
# file is only flushed to disk approximately once per second.
innodb_flush_log_at_trx_commit=1
# The size of the buffer InnoDB uses for buffering log data. As soon as
# it is full, InnoDB will have to flush it to disk. As it is flushed
# once per second anyway, it does not make sense to have it very large
# (even with long transactions).
innodb_log_buffer_size=5M
# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and
# row data. The bigger you set this the less disk I/O is needed to
# access data in tables. On a dedicated database server you may set this
# parameter up to 80% of the machine physical memory size. Do not set it
# too large, though, because competition of the physical memory may
# cause paging in the operating system. Note that on 32bit systems you
# might be limited to 2-3.5G of user level memory per process, so do not
# set it too high.
innodb_buffer_pool_size=32M
# Size of each log file in a log group. You should set the combined size
# of log files to about 25%-100% of your buffer pool size to avoid
# unneeded buffer pool flush activity on log file overwrite. However,
# note that a larger logfile size will increase the time needed for the
# recovery process.
innodb_log_file_size=88M
# Number of threads allowed inside the InnoDB kernel. The optimal value
# depends highly on the application, hardware as well as the OS
# scheduler properties. A too high value may lead to thread thrashing.
innodb_thread_concurrency=8
解決mysql耗內存的具體方法二：
更改後如下：
innodb_buffer_pool_size=576M -256M InnoDB引擎緩衝區佔了大頭，首要就是拿它開刀
query_cache_size=100M -16M 查詢緩存
tmp_table_size=102M -64M 臨時表大小
key_buffer_size=256m -32M
重啟mysql服務後，虛擬內存降到200以下.
另外mysql安裝目錄下有幾個文件：my-huge.ini 、my-large.ini、my-medium.ini…這幾個是根據內存大小作的建議配置，新手在設置的時候也可以參考一下。
2G內存的MYSQL數據庫服務器 my.ini優化 (my.ini)
2G內存,針對站少,優質型的設置,試驗特：
table_cache=1024 物理內存越大,設置就越大.默認為2402,調到512-1024最佳
innodb_additional_mem_pool_size=8M 默認為2M
innodb_flush_log_at_trx_commit=0 等到innodb_log_buffer_size列隊滿後再統一儲存,默認為1
innodb_log_buffer_size=4M 默認為1M
innodb_thread_concurrency=8 你的服務器CPU有幾個就設置為幾,默認為8
key_buffer_size=256M 默認為218 調到128最佳
tmp_table_size=64M 默認為16M 調到64-256最掛
read_buffer_size=4M 默認為64K
read_rnd_buffer_size=16M 默認為256K
sort_buffer_size=32M 默認為256K
max_connections=1024 默認為1210
試驗一：
table_cache=512或1024
innodb_additional_mem_pool_size=2M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=1M
innodb_thread_concurrency=8 你的服務器CPU有幾個就設置為幾,默認為8
key_buffer_size=128M
tmp_table_size=128M
read_buffer_size=64K或128K
read_rnd_buffer_size=256K
sort_buffer_size=512K
max_connections=1024
試驗二：
table_cache=512或1024
innodb_additional_mem_pool_size=8M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=4M
innodb_thread_concurrency=8
key_buffer_size=128M
tmp_table_size=128M
read_buffer_size=4M
read_rnd_buffer_size=16M
sort_buffer_size=32M
max_connections=1024
一般：
table_cache=512
innodb_additional_mem_pool_size=8M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=4M
innodb_thread_concurrency=8
key_buffer_size=128M
tmp_table_size=128M
read_buffer_size=4M
read_rnd_buffer_size=16M
sort_buffer_size=32M
max_connections=1024
經過測試.沒有特殊情況,最好還是用默認的.
2G內存,針對站多,抗壓型的設置,最佳：
table_cache=1024 物理內存越大,設置就越大.默認為2402,調到512-1024最佳
innodb_additional_mem_pool_size=4M 默認為2M
innodb_flush_log_at_trx_commit=1
(設置為0就是等到innodb_log_buffer_size列隊滿後再統一儲存,默認為1)
innodb_log_buffer_size=2M 默認為1M
innodb_thread_concurrency=8 你的服務器CPU有幾個就設置為幾,建議用默認一般為8
key_buffer_size=256M 默認為218 調到128最佳
tmp_table_size=64M 默認為16M 調到64-256最掛
read_buffer_size=4M 默認為64K
read_rnd_buffer_size=16M 默認為256K
sort_buffer_size=32M 默認為256K
max_connections=1024 默認為1210
thread_cache_size=120 默認為60
query_cache_size=64M
優化mysql數據庫性能的十個參數
(1)、max_connections：
允許的同時客戶的數量。增加該值增加 mysqld 要求的文件描述符的數量。這個數字應該增加，否則，你將經常看到 too many connections 錯誤。 默認數值是100，我把它改為1024 。
(2)、record_buffer：
每個進行一個順序掃描的線程為其掃描的每張表分配這個大小的一個緩衝區。如果你做很多順序掃描，你可能想要增加該值。默認數值是131072(128k)，我把它改為16773120 (16m)
(3)、key_buffer_size：
索引塊是緩衝的並且被所有的線程共享。key_buffer_size是用於索引塊的緩衝區大小，增加它可得到更好處理的索引(對所有讀和多重寫)，到你能負擔得起那樣多。如果你使它太大，系統將開始換頁並且真的變慢了。默認數值是8388600(8m)，我的mysql主機有2gb內存，所以我把它改為 402649088(400mb)。
4)、back_log：
要求 mysql 能有的連接數量。當主要mysql線程在一個很短時間內得到非常多的連接請求，這就起作用，然後主線程花些時間(儘管很短)檢查連接並且啟動一個新線程。
back_log 值指出在mysql暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的tcp/ip連接的偵聽隊列的大小。你的操作系統在這個隊列大小上有它自己的限制。試圖設定back_log高於你的操作系統的限制將是無效的。
當你觀察你的主機進程列表，發現大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | null | connect | null | login | null 的待連接進程時，就要加大 back_log 的值了。默認數值是50，我把它改為500。
(5)、interactive_timeout：
服務器在關閉它前在一個交互連接上等待行動的秒數。一個交互的客戶被定義為對 mysql_real_connect()使用 client_interactive 選項的客戶。 默認數值是28800，我把它改為7200。
(6)、sort_buffer：
每個需要進行排序的線程分配該大小的一個緩衝區。增加這值加速order by或group by操作。默認數值是2097144(2m)，我把它改為 16777208 (16m)。
(7)、table_cache：
為所有線程打開表的數量。增加該值能增加mysqld要求的文件描述符的數量。mysql對每個唯一打開的表需要2個文件描述符。默認數值是64，我把它改為512。
(8)、thread_cache_size：
可以復用的保存在中的線程的數量。如果有，新的線程從緩存中取得，當斷開連接的時候如果有空間，客戶的線置在緩存中。如果有很多新的線程，為了提高性能可以這個變量值。通過比較 connections 和 threads_created 狀態的變量，可以看到這個變量的作用。我把它設置為 80。
(9)mysql的搜索功能
用mysql進行搜索，目的是能不分大小寫，又能用中文進行搜索
只需起動mysqld時指定 –default-character-set=gb2312
(10)、wait_timeout：
服務器在關閉它之前在一個連接上等待行動的秒數。 默認數值是28800，我把它改為7200。
註：參數的調整可以通過修改 /etc/my.cnf 文件並重啟 mysql 實現。這是一個比較謹慎的工作，上面的結果也僅僅是我的一些看法，你可以根據你自己主機的硬件情況(特別是內存大小)進一步修改。
mysql數據庫最大連接數可以設置為多少
MySQL服務器的最大並發連接數是16384。
MySQL作為一種開放源代碼的關係型數據庫管理系統（RDBMS），使用最常用的數據庫管理語言結構化查詢語言（SQL）進行數據庫管理。
MySQL服務器的最大並發連接數受服務器配置，及網絡環境等制約，實際服務器支持的並發連接數會小一些，主要決定因素有：
服務器CPU及內存的配置，網絡的帶寬。
互聯網連接中上行帶寬的影響尤為明顯。
擴展資料：
與其他的大型數據庫例如Oracle、IBM DB2、MS SQL等相比，MySQL自有它的不足之處，如規模小、功能有限等，但是這絲毫也沒有減少它受歡迎的程度。對於一般的個人用戶和中小型企業來說，MySQL提供的功能已經綽綽有餘，而且由於MySQL是開放源碼軟件，因此可以大大降低總體擁有成本。
由於這四個軟件都是開放源碼軟件，因此使用這種方式可以以較低的成本創建起一個穩定、免費的網站系統。MySQL加PHP的配對在互聯網上的應用相比LAMP來說更為常見，並獲得了動態配對的雅號，大部分Blog網站基於的WordPress系統主要運用MySQL加PHP的配對。除了LAMP之外，用於Solaris、Windows和Mac上的網站構架也分別被稱為SAMP、WAMP和MAMP。
參考資料來源：百度百科——MySQL數據庫
mysql數據庫最大能支持多少並發量
MySQL服務器的最大並發連接數是16384。
受服務器配置，及網絡環境等制約，實際服務器支持的並發連接數會小一些。主要決定因素有：
1、服務器CPU及內存的配置。
2、網絡的帶寬。互聯網連接中上行帶寬的影響尤為明顯。
擴展資料：
優化數據庫結構：
組織數據庫的schema、表和字段以降低I/O的開銷，將相關項保存在一起，並提前規劃，以便隨着數據量的增長，性能可以保持較高的水平。
設計數據表應盡量使其佔用的空間最小化，表的主鍵應儘可能短。·對於InnoDB表，主鍵所在的列在每個輔助索引條目中都是可複製的，因此如果有很多輔助索引，那麼一個短的主鍵可以節省大量空間。
僅創建需要改進查詢性能的索引。索引有助於檢索，但是會增加插入和更新操作的執行時間。
InnoDB的ChangeBuffering特性：
InnoDB提供了changebuffering的配置，可減少維護輔助索引所需的磁盤I/O。大規模的數據庫可能會遇到大量的表操作和大量的I/O，以保證輔助索引保持最新。當相關頁面不在緩衝池裡面時，InnoDB的changebuffer將會更改緩存到輔助索引條目。
從而避免因不能立即從磁盤讀取頁面而導致耗時的I/O操作。當頁面被加載到緩衝池時，緩衝的更改將被合併，更新的頁面之後會刷新到磁盤。這樣做可提高性能，適用於MySQL5.5及更高版本。
參考資料來源：百度百科-MySQL數據庫
MySQL服務器數量大嗎
不算太大。
MySQL3.22限制的表大小為4GB。由於在MySQL3.23中使用了MyISAM存儲引擎，最大表尺寸增加到了65536TB2567至1字節。由於允許的表尺寸更大，MySQL數據庫的最大有效表尺寸通常是由操作系統對文件大小的限制決定的，而不是由MySQL內部限制決定的。
MySQL是中小型網站普遍使用的數據庫之一，然而很多人並不清楚MySQL到底能支持多大的數據量，再加上某些國內CMS廠商把數據承載量的責任推給它，導致很多不了解MySQL的站長對它產生了很多誤解。
mysql數據庫服務器一般多少內存
我們仍然使用兩個會話，一個會話 run，用於運行主 SQL；另一個會話 ps，用於進行 performance_schema 的觀察：
主會話線程號為 29，
將 performance_schema 中的統計量重置，
臨時表的表大小限制取決於參數 tmp_table_size 和 max_heap_table_size 中較小者，我們實驗中以設置 max_heap_table_size 為例。
我們將會話級別的臨時表大小設置為 2M（小於上次實驗中臨時表使用的空間），執行使用臨時表的 SQL：
查看內存的分配記錄：
會發現內存分配略大於 2M，我們猜測臨時表會比配置略多一點消耗，可以忽略。
查看語句的特徵值：
可以看到語句使用了一次需要落磁盤的臨時表。
那麼這張臨時表用了多少的磁盤呢？
我們開啟 performance_schema 中 waits 相關的統計項：
重做實驗，略過。
再查看 performance_schema 的統計值：
可以看到幾個現象：
1. 臨時表空間被寫入了 7.92MiB 的數據。
2. 這些數據是語句寫入後，慢慢逐漸寫入的。
來看看這些寫入操作的特徵，該方法我們在 實驗 03 使用過：
可以看到寫入的線程是 page_clean_thread，是一個刷臟操作，這樣就能理解數據為什麼是慢慢寫入的。
也可以看到每個 IO 操作的大小是 16K，也就是刷數據頁的操作。
結論：
我們可以看到，
1. MySQL 會基本遵守 max_heap_table_size 的設定，在內存不夠用時，直接將錶轉到磁盤上存儲。
2. 由於引擎不同（內存中表引擎為 heap，磁盤中表引擎則跟隨 internal_tmp_disk_storage_engine 的配置），本次實驗寫磁盤的數據量和 實驗 05 中使用內存的數據量不同。
3. 如果臨時表要使用磁盤，表引擎配置為 InnoDB，那麼即使臨時表在一個時間很短的 SQL 中使用，且使用後即釋放，釋放後也會刷臟頁到磁盤中，消耗部分 IO。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/312553.html
微信掃一掃 
支付寶掃一掃 