當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

mysql最大并行用户设置_mysql 优化配置

發布時間：2025/3/20 数据库 22 豆豆

生活随笔收集整理的這篇文章主要介紹了 mysql最大并行用户设置_mysql 优化配置小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

1、目的：

通過根據服務器目前狀況，修改Mysql的系統參數，達到合理利用服務器現有資源，最大合理的提高MySQL性能。

2、服務器參數：

32G內存、4個CPU,每個CPU?8核。

3、MySQL目前安裝狀況。

MySQL目前安裝，用的是MySQL默認的最大支持配置。拷貝的是my-huge.cnf.編碼已修改為UTF-8.具體修改及安裝MySQL,可以參考<>幫助文檔。

4、修改MySQL配置

打開MySQL配置文件my.cnf

vi??/etc/my.cnf

4.1?MySQL非緩存參數變量介紹及修改

4.1.1修改back_log參數值:由默認的50修改為500.(每個連接256kb,占用：125M)

back_log=500

back_log值不能超過TCP/IP連接的偵聽隊列的大小。若超過則無效，查看當前系統的TCP/IP連接的偵聽隊列的大小命令：cat?/proc/sys/net/ipv4/tcp_max_syn_backlog目前系統為1024。對于Linux系統推薦設置為小于512的整數。

修改系統內核參數，)http://www.51testing.com/html/64/n-810764.html

查看mysql?當前系統默認back_log值，命令：

show?variables?like?'back_log';?查看當前數量

4.1.2修改wait_timeout參數值，由默認的8小時，修改為30分鐘。(本次不用)

wait_timeout=1800(單位為妙)

我對wait-timeout這個參數的理解：MySQL客戶端的數據庫連接閑置最大時間值。

說得比較通俗一點，就是當你的MySQL連接閑置超過一定時間后將會被強行關閉。MySQL默認的wait-timeout??值為8個小時，可以通過命令show?variables?like?'wait_timeout'查看結果值;。

設置這個值是非常有意義的，比如你的網站有大量的MySQL鏈接請求(每個MySQL連接都是要內存資源開銷的?)，由于你的程序的原因有大量的連接請求空閑啥事也不干，白白占用內存資源，或者導致MySQL超過最大連接數從來無法新建連接導致“Too?many?connections”的錯誤。在設置之前你可以查看一下你的MYSQL的狀態(可用show?processlist)，如果經常發現MYSQL中有大量的Sleep進程，則需要?修改wait-timeout值了。

interactive_timeout：服務器關閉交互式連接前等待活動的秒數。交互式客戶端定義為在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶端。

wait_timeout:服務器關閉非交互連接之前等待活動的秒數。在線程啟動時，根據全局wait_timeout值或全局?interactive_timeout值初始化會話wait_timeout值，取決于客戶端類型(由mysql_real_connect()的連接選項CLIENT_INTERACTIVE定義).

這兩個參數必須配合使用。否則單獨設置wait_timeout無效

4.1.3修改max_connections參數值，由默認的151，修改為3000(750M)。

max_connections=3000

max_connections是指MySql的最大連接數，如果服務器的并發連接請求量比較大，建議調高此值，以增加并行連接數量，當然這建立在機器能支撐的情況下，因為如果連接數越多，介于MySql會為每個連接提供連接緩沖區，就會開銷越多的內存，所以要適當調整該值，不能盲目提高設值。可以過'conn%'通配符查看當前狀態的連接數量，以定奪該值的大小。

MySQL服務器允許的最大連接數16384；

查看系統當前最大連接數：

show?variables?like?'max_connections';

4.1..4修改max_user_connections值，由默認的0，修改為800

max_user_connections=800

max_user_connections是指每個數據庫用戶的最大連接

針對某一個賬號的所有客戶端并行連接到MYSQL服務的最大并行連接數。簡單說是指同一個賬號能夠同時連接到mysql服務的最大連接數。設置為0表示不限制。

目前默認值為：0不受限制。

這兒順便介紹下Max_used_connections:它是指從這次mysql服務啟動到現在，同一時刻并行連接數的最大值。它不是指當前的連接情況，而是一個比較值。如果在過去某一個時刻，MYSQL服務同時有1000個請求連接過來，而之后再也沒有出現這么大的并發請求時，則Max_used_connections=1000.請注意與show?variables?里的max_user_connections的區別。默認為0表示無限大。

查看max_user_connections值

show?variables?like?'max_user_connections';

4.1.5修改thread_concurrency值，由目前默認的8，修改為64

thread_concurrency=64

thread_concurrency的值的正確與否,?對mysql的性能影響很大,?在多個cpu(或多核)的情況下，錯誤設置了thread_concurrency的值,?會導致mysql不能充分利用多cpu(或多核),?出現同一時刻只能一個cpu(或核)在工作的情況。

thread_concurrency應設為CPU核數的2倍.?比如有一個雙核的CPU,?那thread_concurrency??的應該為4;?2個雙核的cpu,?thread_concurrency的值應為8.

比如：根據上面介紹我們目前系統的配置，可知道為4個CPU,每個CPU為8核，按照上面的計算規則，這兒應為:4*8*2=64

查看系統當前thread_concurrency默認配置命令：

show?variables?like?'thread_concurrency';

4.1.6添加skip-name-resolve，默認被注釋掉，沒有該參數。

skip-name-resolve

skip-name-resolve：禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！

4.1.7?skip-networking，默認被注釋掉。沒有該參數。(本次無用)

skip-networking建議被注釋掉，不要開啟

開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！

4.1.8??default-storage-engine(設置MySQL的默認存儲引擎)

default-storage-engine=?InnoDB(設置InnoDB類型，另外還可以設置MyISAM類型)

設置創建數據庫及表默認存儲類型

show?table?status?like?‘tablename’顯示表的當前存儲狀態值

查看MySQL有哪些存儲狀態及默認存儲狀態

show?engines;

創建表并指定存儲類型

CREATE?TABLE?mytable?(id?int,?title?char(20))?ENGINE?=?INNODB;

修改表存儲類型：

Alter?table?tableName?engine?=engineName

備注：設置完后把以下幾個開啟：

#?Uncomment?the?following?if?you?are?using?InnoDB?tables

innodb_data_home_dir?=?/var/lib/mysql

#innodb_data_file_path?=?ibdata1:1024M;ibdata2:10M:autoextend(要注釋掉，否則會創建一個新的把原來的替換的。)

innodb_log_group_home_dir?=?/var/lib/mysql

#?You?can?set?.._buffer_pool_size?up?to?50?-?80?%

#?of?RAM?but?beware?of?setting?memory?usage?too?high

innodb_buffer_pool_size?=?1000M

innodb_additional_mem_pool_size?=?20M

#?Set?.._log_file_size?to?25?%?of?buffer?pool?size

innodb_log_file_size?=?500M

innodb_log_buffer_size?=?20M

innodb_flush_log_at_trx_commit?=?0

innodb_lock_wait_timeout?=?50

設置完后一定記得把MySQL安裝目錄地址(我們目前是默認安裝所以地址/var/lib/mysql/)下的ib_logfile0和ib_logfile1刪除掉。否則重啟MySQL起動失敗。

4.2?MySQL緩存變量介紹及修改

數據庫屬于IO密集型的應用程序，其主職責就是數據的管理及存儲工作。而我們知道，從內存中讀取一個數據庫的時間是微秒級別，而從一塊普通硬盤上讀取一個?IO是在毫秒級別，二者相差3個數量級。所以，要優化數據庫，首先第一步需要優化的就是IO，盡可能將磁盤IO轉化為內存IO。本文先從MySQL數據庫?IO相關參數(緩存參數)的角度來看看可以通過哪些參數進行IO優化

4.2.1全局緩存

啟動MySQL時就要分配并且總是存在的全局緩存。目前有：key_buffer_size(默認值：402653184,即384M)、innodb_buffer_pool_size(默認值：134217728即：128M)、innodb_additional_mem_pool_size(默認值：8388608即：8M)、innodb_log_buffer_size(默認值：8388608即：8M)、query_cache_size(默認值：33554432即：32M)等五個。總共：560M.

這些變量值都可以通過命令如：show?variables?like?'變量名';查看到。

4.2.1.1：key_buffer_size,本系統目前為384M,可修改為400M

key_buffer_size=400M

key_buffer_size是用于索引塊的緩沖區大小，增加它可得到更好處理的索引(對所有讀和多重寫)，對MyISAM(MySQL表存儲的一種類型，可以百度等查看詳情)表性能影響最大的一個參數。如果你使它太大，系統將開始換頁并且真的變慢了。嚴格說是它決定了數據庫索引處理的速度，尤其是索引讀的速度。對于內存在4GB左右的服務器該參數可設置為256M或384M.

怎么才能知道key_buffer_size的設置是否合理呢，一般可以檢查狀態值Key_read_requests和Key_reads???，比例key_reads?/?key_read_requests應該盡可能的低，比如1:100，1:1000?，1:10000。其值可以用以下命令查得：show?status?like?'key_read%';

比如查看系統當前key_read和key_read_request值為：

+-------------------+-------+

|?Variable_name?????|?Value?|

+-------------------+-------+

|?Key_read_requests?|?28535?|

|?Key_reads?????????|?269???|

+-------------------+-------+

可知道有28535個請求，有269個請求在內存中沒有找到直接從硬盤讀取索引.

未命中緩存的概率為：0.94%=269/28535*100%.??一般未命中概率在0.1之下比較好。目前已遠遠大于0.1，證明效果不好。若命中率在0.01以下，則建議適當的修改key_buffer_size值。

http://dbahacker.com/mysql/innodb-myisam-compare(InnoDB與MyISAM的六大區別)

http://kb.cnblogs.com/page/99810/(查看存儲引擎介紹)

MyISAM、InnoDB、MyISAM?Merge引擎、InnoDB、memory(heap)、archive

4.2.1.2：innodb_buffer_pool_size(默認128M)

innodb_buffer_pool_size=1024M(1G)

innodb_buffer_pool_size:主要針對InnoDB表性能影響最大的一個參數。功能與Key_buffer_size一樣。InnoDB占用的內存，除innodb_buffer_pool_size用于存儲頁面緩存數據外，另外正常情況下還有大約8%的開銷，主要用在每個緩存頁幀的描述、adaptive?hash等數據結構，如果不是安全關閉，啟動時還要恢復的話，還要另開大約12%的內存用于恢復，兩者相加就有差不多21%的開銷。假設：12G的innodb_buffer_pool_size，最多的時候InnoDB就可能占用到14.5G的內存。若系統只有16G，而且只運行MySQL，且MySQL只用InnoDB，

那么為MySQL開12G，是最大限度地利用內存了。

另外InnoDB和?MyISAM?存儲引擎不同，?MyISAM?的?key_buffer_size?只能緩存索引鍵，而?innodb_buffer_pool_size?卻可以緩存數據塊和索引鍵。適當的增加這個參數的大小，可以有效的減少?InnoDB?類型的表的磁盤?I/O?。

當我們操作一個?InnoDB?表的時候，返回的所有數據或者去數據過程中用到的任何一個索引塊，都會在這個內存區域中走一遭。

可以通過?(Innodb_buffer_pool_read_requests?–?Innodb_buffer_pool_reads)?/?Innodb_buffer_pool_read_requests?*?100%?計算緩存命中率，并根據命中率來調整?innodb_buffer_pool_size?參數大小進行優化。值可以用以下命令查得：show?status?like?'Innodb_buffer_pool_read%';

比如查看當前系統中系統中

|?Innodb_buffer_pool_read_requests??????|?1283826?|

|?Innodb_buffer_pool_reads??????????????|?519?????|

+---------------------------------------+---------+

其命中率99.959%=(1283826-519)/1283826*100%??命中率越高越好。

4.2.1.3：innodb_additional_mem_pool_size(默認8M)

innodb_additional_mem_pool_size=20M

innodb_additional_mem_pool_size?設置了InnoDB存儲引擎用來存放數據字典信息以及一些內部數據結構的內存空間大小，所以當我們一個MySQL?Instance中的數據庫對象非常多的時候，是需要適當調整該參數的大小以確保所有數據都能存放在內存中提高訪問效率的。

這個參數大小是否足夠還是比較容易知道的，因為當過小的時候，MySQL會記錄Warning信息到數據庫的error?log中，這時候你就知道該調整這個參數大小了。

查看當前系統mysql的error日志??cat??/var/lib/mysql/機器名.error?發現有很多waring警告。所以要調大為20M.

根據MySQL手冊，對于2G內存的機器，推薦值是20M。

32G內存的?100M

4.2.1.4：innodb_log_buffer_size(默認8M)

innodb_log_buffer_size=20M

innodb_log_buffer_size??這是InnoDB存儲引擎的事務日志所使用的緩沖區。類似于Binlog?Buffer，InnoDB在寫事務日志的時候，為了提高性能，也是先將信息寫入Innofb?Log?Buffer中，當滿足innodb_flush_log_trx_commit參數所設置的相應條件(或者日志緩沖區寫滿)之后，才會將日志寫到文件?(或者同步到磁盤)中。可以通過innodb_log_buffer_size?參數設置其可以使用的最大內存空間。

InnoDB?將日志寫入日志磁盤文件前的緩沖大小。理想值為?1M?至?8M。大的日志緩沖允許事務運行時不需要將日志保存入磁盤而只到事務被提交(commit)。?因此，如果有大的事務處理，設置大的日志緩沖可以減少磁盤I/O。?在?my.cnf中以數字格式設置。

默認是8MB，系的如頻繁的系統可適當增大至4MB～8MB。當然如上面介紹所說，這個參數實際上還和另外的flush參數相關。一般來說不建議超過32MB

注：innodb_flush_log_trx_commit參數對InnoDB?Log的寫入性能有非常關鍵的影響,默認值為1。該參數可以設置為0，1，2，解釋如下：

0：log?buffer中的數據將以每秒一次的頻率寫入到log?file中，且同時會進行文件系統到磁盤的同步操作，但是每個事務的commit并不會觸發任何log?buffer?到log?file的刷新或者文件系統到磁盤的刷新操作;

1：在每次事務提交的時候將log?buffer?中的數據都會寫入到log?file，同時也會觸發文件系統到磁盤的同步;

2：事務提交會觸發log?buffer到log?file的刷新，但并不會觸發磁盤文件系統到磁盤的同步。此外，每秒會有一次文件系統到磁盤同步操作。

實際測試發現，該值對插入數據的速度影響非常大，設置為2時插入10000條記錄只需要2秒，設置為0時只需要1秒，而設置為1時則需要229秒。因此，MySQL手冊也建議盡量將插入操作合并成一個事務，這樣可以大幅提高速度。根據MySQL手冊，在存在丟失最近部分事務的危險的前提下，可以把該值設為0。

4.5.1.5：query_cache_size(默認32M)

query_cache_size=40M

query_cache_size:?主要用來緩存MySQL中的ResultSet，也就是一條SQL語句執行的結果集，所以僅僅只能針對select語句。當我們打開了?Query?Cache功能，MySQL在接受到一條select語句的請求后，如果該語句滿足Query?Cache的要求(未顯式說明不允許使用Query?Cache，或者已經顯式申明需要使用Query?Cache)，MySQL會直接根據預先設定好的HASH算法將接受到的select語句以字符串方式進行hash，然后到Query?Cache中直接查找是否已經緩存。也就是說，如果已經在緩存中，該select請求就會直接將數據返回，從而省略了后面所有的步驟(如SQL語句的解析，優化器優化以及向存儲引擎請求數據等)，極大的提高性能。根據MySQL用戶手冊，使用查詢緩沖最多可以達到238%的效率。

當然，Query?Cache也有一個致命的缺陷，那就是當某個表的數據有任何任何變化，都會導致所有引用了該表的select語句在Query?Cache中的緩存數據失效。所以，當我們的數據變化非常頻繁的情況下，使用Query?Cache可能會得不償失

Query?Cache的使用需要多個參數配合，其中最為關鍵的是query_cache_size和query_cache_type，前者設置用于緩存?ResultSet的內存大小，后者設置在何場景下使用Query?Cache。在以往的經驗來看，如果不是用來緩存基本不變的數據的MySQL數據庫，query_cache_size一般256MB是一個比較合適的大小。當然，這可以通過計算Query?Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))來進行調整。?query_cache_type可以設置為0(OFF)，1(ON)或者2(DEMOND)，分別表示完全不使用query?cache，除顯式要求不使用query?cache(使用sql_no_cache)之外的所有的select都使用query?cache，只有顯示要求才使用query?cache(使用sql_cache)。如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖.?如果Qcache_hits的值也非常大，則表明查詢緩沖使用非常頻繁，此時需要增加緩沖大小；

根據命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))進行調整，一般不建議太大，256MB可能已經差不多了，大型的配置型靜態數據可適當調大.

可以通過命令：show?status?like?'Qcache_%';查看目前系統Query?catch使用大小

|?Qcache_hits?????????????|?1892463??|

|?Qcache_inserts??????????|?35627

命中率98.17%=1892463/(1892463?+35627?)*100

4.2.2局部緩存

除了全局緩沖，MySql還會為每個連接發放連接緩沖。個連接到MySQL服務器的線程都需要有自己的緩沖。大概需要立刻分配256K，甚至在線程空閑時，它們使用默認的線程堆棧，網絡緩存等。事務開始之后，則需要增加更多的空間。運行較小的查詢可能僅給指定的線程增加少量的內存消耗，然而如果對數據表做復雜的操作例如掃描、排序或者需要臨時表，則需分配大約read_buffer_size，

sort_buffer_size，read_rnd_buffer_size，tmp_table_size?大小的內存空間.?不過它們只是在需要的時候才分配，并且在那些操作做完之后就釋放了。有的是立刻分配成單獨的組塊。tmp_table_size?可能高達MySQL所能分配給這個操作的最大內存空間了

。注意，這里需要考慮的不只有一點——可能會分配多個同一種類型的緩存，例如用來處理子查詢。一些特殊的查詢的內存使用量可能更大——如果在MyISAM表上做成批的插入

時需要分配?bulk_insert_buffer_size?大小的內存；執行?ALTER?TABLE，?OPTIMIZE?TABLE，?REPAIR?TABLE?命令時需要分配?myisam_sort_buffer_size?大小的內存。

4.2.2.1：read_buffer_size(默認值：2097144即2M)

read_buffer_size=4M

read_buffer_size?是MySql讀入緩沖區大小。對表進行順序掃描的請求將分配一個讀入緩沖區，MySql會為它分配一段內存緩沖區。read_buffer_size變量控制這一

緩沖區的大小。如果對表的順序掃描請求非常頻繁，并且你認為頻繁掃描進行得太慢，可以通過增加該變量值以及內存緩沖區大小提高其性能.

4.2.2.2：sort_buffer_size(默認值：2097144即2M)

sort_buffer_size=4M

sort_buffer_size是MySql執行排序使用的緩沖大小。如果想要增加ORDER?BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能，可以嘗試增加sort_buffer_size變量的大小

4.2.2.3:??read_rnd_buffer_size(默認值：8388608即8M)

read_rnd_buffer_size=8M

read_rnd_buffer_size?是MySql的隨機讀緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩沖，以避免磁盤搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySql會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開

銷過大。

4.2.2.4:??tmp_table_size(默認值：8388608?即：16M)

tmp_table_size=16M

tmp_table_size是MySql的heap?(堆積)表緩沖大小。所有聯合在一個DML指令內完成，并且大多數聯合甚至可以不用臨時表即可以完成。大多數臨時表是基于內

存的(HEAP)表。具有大的記錄長度的臨時表?(所有列的長度的和)或包含BLOB列的表存儲在硬盤上。如果某個內部heap(堆積)表大小超過tmp_table_size，MySQL可以根據需要自

動將內存中的heap表改為基于硬盤的MyISAM表。還可以通過設置tmp_table_size選項來增加臨時表的大小。也就是說，如果調高該值，MySql同時將增加heap表的大小，可達到提高

聯接查詢速度的效果。

4.2.2.5：record_buffer:(默認值：)

record_buffer每個進行一個順序掃描的線程為其掃描的每張表分配這個大小的一個緩沖區。如果你做很多順序掃描，你可能想要增加該值。默認數值是131072

(128K)

4.2.3其它緩存：

4.2.3.1：table_cache(默認值：512)

TABLE_CACHE(5.1.3及以后版本又名TABLE_OPEN_CACHE)

table_cache指定表高速緩存的大小。每當MySQL訪問一個表時，如果在表緩沖區中還有空間，該表就被打開并放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等于table_cache，并且opened_tables在不斷增長，那么你就需要增加table_cache的值了(上述狀態值可以使用SHOW?STATUS?LIKE?‘Open%tables’獲得)。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成文件描述符不足，從而造成性能不穩定或者連接失敗。

SHOW?STATUS?LIKE?'Open%tables';

+---------------+-------+

|?Variable_name?|?Value?|

+---------------+-------+

|?Open_tables???|?356???|

|?Opened_tables?|?0?????|

+---------------+-------+

2?rows?in?set?(0.00?sec)

open_tables表示當前打開的表緩存數，如果執行flush?tables操作，則此系統會關閉一些當前沒有使用的表緩存而使得此狀態值減小；

opend_tables表示曾經打開的表緩存數，會一直進行累加，如果執行flush?tables操作，值不會減小。

在mysql默認安裝情況下，table_cache的值在2G內存以下的機器中的值默認時256到512，如果機器有4G內存,則默認這個值?是2048，但這決意味著機器內存越大，這個值應該越大，因為table_cache加大后，使得mysql對SQL響應的速度更快了，不可避免的會產生?更多的死鎖(dead?lock)，這樣反而使得數據庫整個一套操作慢了下來，嚴重影響性能。所以平時維護中還是要根據庫的實際情況去作出判斷，找到最適合你維護的庫的?table_cache值。

由于MySQL是多線程的機制,為了提高性能,每個線程都是獨自打開自己需要的表的文件描?述符,而不是通過共享已經打開的.針對不同存儲引擎處理的方法當然也不一樣

在myisam表引擎中,數據文件的描述符?(descriptor)是不共享的,但是索引文件的描述符卻是所有線程共享的.Innodb中和使用表空間類型有關,假如是共享表空間那么實際就一個數?據文件,當然占用的數據文件描述符就會比獨立表空間少.

mysql手冊上給的建議大小?是:table_cache=max_connections*n

n表示查詢語句中最大表數,?還需要為臨時表和文件保留一些額外的文件描述符。

這個數據遭到很多質疑,table_cache夠用就好,檢查?Opened_tables值,如果這個值很大,或增長很快那么你就得考慮加大table_cache了.

table_cache：所有線程打開的表的數目。增大該值可以增加mysqld需要的文件描述符的數量。默認值是64.

4.2.3.2?thread_cache_size?(服務器線程緩存)

thread_cache_size=64

默認的thread_cache_size=8，但是看到好多配置的樣例里的值一般是32，64，甚至是128，感覺這個參數對優化應該有幫助，于是查了下：

根據調查發現以上服務器線程緩存thread_cache_size沒有進行設置，或者設置過小,這個值表示可以重新利用保存在緩存中線程的數量,當斷開連接時如果緩存中還有空間,那么客戶端的線程將被放到緩存中,如果線程重新被請求，那么請求將從緩存中讀取,如果緩存中是空的或者是新的請求，那么這個線程將被重新創建,如果有很多新的線程，增加這個值可以改善系統性能.通過比較?Connections?和?Threads_created?狀態的變量，可以看到這個變量的作用。(–>表示要調整的值)???根據物理內存設置規則如下：

1G?—>?8

2G?—>?16

3G?—>?32?????>3G?—>?64

mysql>?show?status?like?'thread%';

+——————-+——-+

|?Variable_name?????|?Value?|

+——————-+——-+

|?Threads_cached????|?0?????|??

|?Threads_connected?|?1?????|??

|?Threads_created???|?1498??|??

|?Threads_running???|?1?????|??

+——————-+——-+

查看開機起來數據庫被連接了多少次？

mysql>?show?status?like?'%connection%';

+———————-+——-+

|?Variable_name????????|?Value?|

+———————-+——-+

|?Connections??????????|?1504??|??????????–>服務啟動以來，歷史連接數

|?Max_used_connections?|?2?????|

+———————-+——-+

通過連接線程池的命中率來判斷設置值是否合適？命中率超過90%以上,設定合理。

(Connections?-??Threads_created)?/?Connections?*?100?%

5.查看命令總結

5.1.0查看各參數內存配置方式

#全局共享內存 9個變量

show variables like 'innodb_buffer_pool_size'; /* InnoDB 數據和索引緩存(InnoDB Buffer Pool) */

show variables like 'innodb_additional_mem_pool_size'; /* InnoDB 字典信息緩存(InnoDB Additional Memory Pool)*/

show variables like 'innodb_log_buffer_size'; /* InnoDB 日志緩沖區(InnoDB Log Buffer) */

show variables like 'binlog_cache_size'; /* 二進制日志緩沖區(Binlog Buffer)*/

show variables like 'thread_cache_size'; /* 連接線程緩存(Thread Cache)*/

show variables like 'query_cache_size'; /* 查詢緩存(Query Cache)*/

show variables like 'table_open_cache'; /* 表緩存(Table Cache) */

show variables like 'table_definition_cache'; /* 表定義信息緩存(Table definition Cache) */

show variables like 'key_buffer_size'; /* MyISAM索引緩存(Key Buffer) */

#最大線程數

show variables like 'max_connections';

#線程獨享內存 6個變量

show variables like 'thread_stack'; /* 線線程棧信息使用內存(thread_stack) */

show variables like 'sort_buffer_size'; /* 排序使用內存(sort_buffer_size) */

show variables like 'join_buffer_size'; /* Join操作使用內存(join_buffer_size) */

show variables like 'read_buffer_size'; /* 順序讀取數據緩沖區使用內存(read_buffer_size) */

show variables like 'read_rnd_buffer_size'; /* 隨機讀取數據緩沖區使用內存(read_rnd_buffer_size) */

show variables like 'tmp_table_size'; /* 臨時表使用內存(tmp_table_size) ，我實際計算把tmp_table_size放入全局共享內*/

也可以通過系統變量的方式直接獲取

select @@key_buffer_size;

select @@max_connections

5.1.1mysql內存計算公式

mysql使用的內存 = 全局共享內存+最大線程數×線程獨享內存

mysql used

mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size

+max_connections*(

thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size+tmp_table_size)

SET @kilo_bytes=1024;

SET @mega_bytes=@kilo_bytes*1024;

SET @giga_bytes=@mega_bytes*1024;

SELECT

(@@innodb_buffer_pool_size+@@innodb_additional_mem_pool_size+@@innodb_log_buffer_size+@@binlog_cache_size+@@thread_cache_size+@@query_cache_size+@@table_open_cache+@@table_definition_cache+@@key_buffer_size+@@max_connections*(@@thread_stack+@@sort_buffer_size+@@join_buffer_size+@@read_buffer_size+@@read_rnd_buffer_size+@@tmp_table_size))/@giga_bytes

AS MAX_MEMORY_GB;

這個理論最大的內存使用量，在5.5版本中tmp_table_size默認是16M，按默認u自大連接數151計算，光線程獨享的臨時表占據的空間都是2416M，我實際計算把tmp_table_size放入全局共享內

我的計算公式

mysql使用的內存 = 全局共享內存+最大線程數×線程獨享內存

mysql used

mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size+tmp_table_size

+max_connections*(

thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size)

總結

以上是生活随笔為你收集整理的mysql最大并行用户设置_mysql 优化配置的全部內容，希望文章能夠幫你解決所遇到的問題。

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

上一篇： mysql ddl dcl_MySQL常
下一篇： python 美化输出错误警告等信息