2022mysql運維操作手冊

第第頁Mysql運維操作手冊2022目錄TOC\o"1-3"\h\z\u1、簡介 71.1目的 71.2適用范圍 71.3引用文件 71.4特別聲明 72、操作系統(tǒng)參數(shù) 72.1內(nèi)核參數(shù)sysconf 72.1.1somaxconn 72.1.2tcp_max_syn_backlog 72.1.3netdev_max_backlog 72.1.4tcp_fin_timeout 82.1.5tcp_tw_reuse 82.1.6tcp_tw_recycle 82.1.7網(wǎng)絡相關 82.1.8心跳檢測 82.1.9內(nèi)存頁分配 82.1.10交換內(nèi)存 92.2資源限制 92.2.1參考樣例 92.2.2其它配置 93、常用參數(shù) 93.1三種方式 93.1.1全局方式 93.1.2會話方式 103.1.3配置方式 103.2connection相關 103.2.1max_connections 103.2.2max_user_connections 103.2.3Threads 103.2.4back_log 113.2.5超時設置 113.2.6查看連接 113.3查詢緩存 123.3.1表緩存 123.3.2查詢緩存狀態(tài) 133.3.3設置緩存參數(shù) 143.4innodb相關 153.4.1innodb_buffer_pool_% 153.4.2其它參數(shù) 163.5日志優(yōu)化 183.5.1binlog日志 183.5.2事務區(qū)日志 193.5.3復制優(yōu)化 193.6事務隔離 203.6.1READUNCOMMITTED 213.6.2READCOMMITTED 213.6.3REPEATABLEREAD 213.6.4SERIALIZABLE 213.6.5綜合建議 223.7會話參數(shù) 223.7.1sort_buffer_size 223.8其它參數(shù) 224、常用性能監(jiān)控 224.1查詢總視圖 224.2查詢連接 234.2.1列表查詢 234.2.2查詢長時間連接 244.3查詢慢SQL 244.3.1開啟慢查詢 244.3.2統(tǒng)計排名 254.4查詢分析 254.4.1開啟查詢 254.5查看各表統(tǒng)計信息 254.6分析表執(zhí)行計劃 264.7查詢當前進程 264.7.1查詢進程 264.7.2主要狀態(tài) 264.8狀態(tài)查詢 284.9鎖監(jiān)控查詢 294.9.1查詢鎖表情況 294.9.2查詢當前事務鎖 294.9.3查詢當前鎖表 294.9.4查詢被鎖事務 294.9.5查詢到鎖源 304.9.6查詢鎖源sql語句 314.9.7快速方法 314.10performance_schema 334.10.1開啟說明 334.10.2表分類說明 334.10.3簡單使用 344.10.4系統(tǒng)變量 344.10.5啟動選項 354.10.6重要配置表 364.10.7常用監(jiān)控 394.11Profiler(診斷) 434.11.1開啟 434.11.2查看最近 444.11.3顯示明細 444.11.4顯示cpu|block 455、內(nèi)存評估 465.1內(nèi)存參數(shù) 465.2mysql內(nèi)存公式 475.3mysql內(nèi)存計算 475.4mysql磁盤參數(shù)優(yōu)化 486、參考文章 48簡介目的本文檔為xxx信息有限公司針mysql運維操作手冊。編寫此操作手冊的目的在于幫助現(xiàn)研發(fā)、測試和實施人員安裝部署系統(tǒng)，提高工作效率。適用范圍實施人員、項目經(jīng)理、項目成員。引用文件無特別聲明操作系統(tǒng)參數(shù)內(nèi)核參數(shù)sysconfsomaxconn#系統(tǒng)允許同時發(fā)起的TCP連接數(shù)。在許多的主流操作系統(tǒng)上這個值都默認是128。net.core.somaxconn=65535tcp_max_syn_backlog#系統(tǒng)允許的半連接(SYN)同步包上限，顯然tcp_max_syn_backlog>=somaxconnnet.ipv4.tcp_max_syn_backlog=65536netdev_max_backlog#每個網(wǎng)絡端口接收數(shù)據(jù)包的速率比內(nèi)核處理這些包的速率快時，允許送到隊列的數(shù)據(jù)包的最大數(shù)目dev_max_backlog=65536tcp_fin_timeout#這個參數(shù)是用來設置保持在FIN_WAIT_2狀態(tài)的時間。tcp4次揮手，正常的處理流程就是在FIN_WAIT_2情況下接收到FIN進入到TIME_WAIT的情況，tcp_fin_timeout參數(shù)對處于TIME_WAIT狀態(tài)的時間沒有任何影響。但是如果這個參數(shù)設的比較小，會縮短從FIN_WAIT_2到TIME_WAIT的時間，從而使連接更早地進入TIME_WAIT狀態(tài)。狀態(tài)開始的早，等待相同的時間，結束的也早，客觀上也加速了TIME_WAIT狀態(tài)套接字的清理速度。net.ipv4.tcp_fin_timeout=10tcp_tw_reuse#TIME-WAIT套接字是否允許重用于新的TCP連接,了解網(wǎng)絡建議開啟=1,提高連接速度,net.ipv4.tcp_tw_reuse=1tcp_tw_recycle##表示開啟TCP連接中TIME-WAITsockets的快速回收，默認為0，表示關閉。net.ipv4.tcp_tw_recycle=0網(wǎng)絡相關#發(fā)送與接收數(shù)據(jù)的緩存值net.core.wmem_default=87380

net.core.wmem_max=16777216

net.core.rmem_default=87380

net.core.rmem_max=16777216心跳檢測#長連接的心跳包機制#設置心跳包開始時機為,發(fā)送數(shù)據(jù)包后半小時開始心跳檢查net.ipv4.tcp_keepalive_time=1800#心跳包發(fā)送間隔時間10秒net.ipv4.tcp_keepalive_intvl=10#超過3次沒有應答,則認為連接無效,將其丟棄net.ipv4.tcp_keepalive_probes=3內(nèi)存頁分配#kernel.shmall=_PHYS_PAGES/2#參考物理內(nèi)存頁的一半,主機32G內(nèi)存，參考如下kernel.shmall=4194304#kernel.shmmax=kernel.shmall*PAGE_SIZE#主機32G內(nèi)存，參考如下kernel.shmmaxernel.shmmni=4096#kernel.shmmax必須大于INNODB_POOL_SIZE與QUERY_CACHE及其他MySQL占用內(nèi)存總和，#建議總內(nèi)存的60%左右kernel.shmmax=2147483648交換內(nèi)存vm.swappiness=1vm.dirty_background_bytes=536870912資源限制參考樣例vim

/etc/security/limits.conf*softnofile524288*hardnofile524288*softnprocunlimited*hardnprocunlimited*softmemlockunlimited*hardmemlockunlimited*softstackunlimited*hardstackunlimited*softcoreunlimited*hardcoreunlimited其它配置cat/etc/security/limits.d/20-nproc.conf常用參數(shù)三種方式全局方式showVARIABLESlike'%connection%'#setGlobal在Mysql服務器運行過程中會一直生效,直到mysql關閉#值得注意的是:部分參數(shù)在setglobal并不會立即生效,需要重新建立連接后才有效setGLOBALmax_connections=200;會話方式#setsession代表在當前會話(窗口/連接)才有效,關閉會話后自動失效#參數(shù)設置的優(yōu)先級session>global>配置文件setxxx=xxx;session可以去掉，默認就是會話方式配置方式在f中設置connection相關max_connections#max_connections代表數(shù)據(jù)庫同時允許的最大允許連接數(shù)#連接有兩種常見狀態(tài):sleep/query#sleep代表連接處于閑置狀態(tài)#query代表連接正處于處理任務的狀態(tài)#sleep+query連接的總量不能超過max_connections的設置值#否則會出現(xiàn)經(jīng)典錯誤:"ERROR1040：Toomanyconnetcions"showVARIABLESlike'max_connections';setglobalmax_connections=300;max_user_connections每個用戶允許的最大連接數(shù)Threadsshowstatuslike'Threads%';#Threads_connected代表當前已經(jīng)有多少連接(Sleep+Query)#Threads_created代表歷史總共創(chuàng)建過多少個數(shù)據(jù)庫連接#Threads_running代表有幾個連接正處于"工作"狀態(tài),也是目前的并發(fā)數(shù)#Threads_cached共緩存過多少連接.如果我們在MySQL服務器配置文件中設置了thread_cache_size，當客戶端斷開之后，服務器處理此客戶的線程將會緩存起來以響應下一個客戶而不是銷毀(前提是緩存數(shù)未達上限)。setglobalthread_cache_size=80;#MySQL歷史運行過程中最大連接數(shù)的數(shù)量及時點showstatuslike'Max_used_connections%';根據(jù)Connections和Threads_created這兩個系統(tǒng)狀態(tài)值，我們還可以計算出系統(tǒng)新建連接連接的ThreadCache命中率，也就是通過ThreadCache池中取得連接線程的次數(shù)與系統(tǒng)接收的總連接次數(shù)的比率，如下：Threads_Cache_Hit=(Connections-Threads_created)/Connections*100%back_log#back_log設置保存多少數(shù)據(jù)庫請求到堆棧(緩沖區(qū))中.#也就是說，如果MySql的連接數(shù)達到max_connections時，新來的請求將會被存在堆棧中，以等待某一連接釋放資源，該堆棧的數(shù)量即back_log，如果等待連接的數(shù)量超過back_log，將不被授予連接資源。將會報：unauthenticateduser|xxx.xxx.xxx.xxx|NULL|Connect|NULL|login|NULL的待連接進程時.showVARIABLESLIKE'back_log'超時設置#wait_timeout和interactive_timeout#這兩個參數(shù)都是至超過一段時間后,數(shù)據(jù)庫連接自動關閉(默認28800秒,即8小時)#interactive_timeout針對交互式連接，wait_timeout針對非交互式連接。#說得直白一點，通過mysql客戶端連接數(shù)據(jù)庫是交互式連接，通過jdbc連接數(shù)據(jù)庫是非交互式連接。showVARIABLESLIKE'wait_timeout';showVARIABLESLIKE'interactive_timeout';查看連接#查看當前數(shù)據(jù)庫連接詳細狀況showprocesslist;查詢緩存表緩存table_definition_cache全局參數(shù)，默認值為-1，最小是為400，描述的是.frm文件在定義換成里面存儲的總量，如果你創(chuàng)建一個比較大的值，會加快你打開表的速度。這個表定義緩存會占據(jù)一些空間，它不同于常規(guī)的表緩存，它不會用文件描述符。它的值，最小400，之后一般依據(jù)下面的簡單計算來定：400+(table_open_cache/2)table_open_cache這也是全局參數(shù)，默認是2000，最小值1最大值524288，這是mysql服務器當前所有線程打開的表的數(shù)據(jù)量，增加這個值會增加mysqld需要的文件描述符的數(shù)量。可以通過檢查Opened_tables狀態(tài)變量來檢查是否需要增加表緩存。FLUSHTABLES命令會強迫所有的表去關閉然后重新打開。但是table_open_cache一般是可以調(diào)整增加的，但是不能超過shell文件的上限，就是-ulimit-a的那個值table_open_cache_instances全局參數(shù)，默認16，最小1，最大64，打開的表緩存實例的數(shù)量。為了通過減少會話間的爭用來提高可伸縮性，可以將打開的表緩存劃分為幾個大小為table_open_cache/table_open_cache_instances的較小緩存實例。一個會話只需要鎖定一個實例就可以訪問DML語句從下面這個圖我們可以看出表緩存需要設置的大小，一般命中率太低，我們建議適當增加該值查詢緩存狀態(tài)showstatuslike'Qcache%';#Qcache_free_memory:QueryCache中目前剩余的內(nèi)存大小。通過這個參數(shù)我們可以較為準確的觀察當前系統(tǒng)中的QueryCache內(nèi)存大小是否足夠，是需要增多還是過多了。#Qcache_lowmen_prunes：多少條Query因為內(nèi)存不足而被清除出QueryCache，通過Qcache_lowmem_prunes和Qcache_free_memory相互結合，能夠更清楚的了解到我們系統(tǒng)中QueryCache的內(nèi)存大小是否真的足夠，是否非常頻繁的出現(xiàn)因為內(nèi)存不足而有Query被換出。這個數(shù)字最好是長時間來看，如果這個數(shù)字在不斷增長，就表示可能碎片化非常嚴重，或者內(nèi)存很少。#Qcache_total_blocks：當前QueryCache中block的數(shù)量#Qcache_free_blocks：緩存中相鄰內(nèi)存塊的個數(shù)。如果該值顯示過大，則說明QueryCache中的內(nèi)存碎片較多了。#查詢緩存碎片率：Qcache_free_block/Qcache_total_block*100%#如果查詢緩存碎片率超過20%，可以用flushquerycache整理緩存碎片#Block默認是4KB，設置值大對大數(shù)據(jù)查詢有好處，但是如果你查詢的都是小數(shù)據(jù)查詢，就容易造成內(nèi)存碎片和浪費。#Qcache_hits：表示有多少次命中緩存。我們主要可以通過該值來驗證我們的查詢能緩存的效果。數(shù)字越大緩存效果越理想。#Qcache_inserts：表示多少次未命中而插入，意思是新來的SQL請求在緩存中未找到，不得不執(zhí)行查詢處理，執(zhí)行查詢處理后把結果insert帶查詢緩存中。這樣的情況次數(shù)越多，表示查詢緩存應用到的比較少，效果也就不理想。#Qcache_queries_in_cache:當前緩存中緩存的查詢數(shù)量。#Qcache_not_cached未進入查詢緩存的select個數(shù)設置緩存參數(shù)showglobalvariableslike'query_cache_%';#query_cache_size：查詢緩存大?。ㄗⅲ篞C存儲的單位最小是1024byte，所以如果你設定的一個不是1024的倍數(shù)的值。這個值會被四舍五入到最接近當前值的等于1024的倍數(shù)的值。）#query_cache_limit：超出此大小的查詢將不被緩存#1mb,超過1mb的結果將不緩存showVARIABLESlike'query_cache_limit';setglobalquery_cache_limit=10485760;#query_cache_type：緩存類型，決定緩存什么樣子的查詢，注意這個值不能隨便設置必須設置為數(shù)字，可選值以及說明如下：0：OFF相當于禁用了1：ON將緩存所有結果，除非你的select語句使用了SQL_NO_CACHE禁用了查詢緩存2：DENAND則只緩存select語句中通過SQL_CACHE指定需要緩存的查詢。#5.7中默認禁用QC,需要在my.ini中進行開啟showVARIABLESlike'query_cache_type';setglobalquery_cache_type=1;#query_cache_min_res_unit：緩存塊的最小大小，query_cache_min_res_unit的配置是一柄雙刃劍，默認是4KB，設置值大對大數(shù)據(jù)查詢有好處，但是如果你查詢的都是小數(shù)據(jù)查詢，就容易造成內(nèi)存碎片和浪費。#每個查詢占用緩存的平均值=（query_cache_size-Qcache_free_memory）/Qcache_queries_in_cache#查詢緩存利用率：（query_cache_size-Qcache_free_memory)/query_cache_size*100%查詢緩存利用率在25%以下的話說明query_cache_size設置過大，可以適當減小：查詢緩存利用率在80%以上而且Qcache_lowmem_prunes>50的話說明query_cache_size可能有點小，要不就是碎片太多#查詢緩存命中率：Qcache_hits/(Qcache_hits+Qcache_inserts)*100% innodb相關innodb_buffer_pool_%showstatuslike'Innodb_buffer_pool_%';innodb_buffer_pool_size#134217728=128M(默認值)innodb_buffer_pool_size參數(shù)用來設置Innodb最主要的Buffer(Innodb_Buffer_Pool)的大小，也就是緩存用戶表及索引數(shù)據(jù)的最主要緩存空間，對Innodb整體性能影響也最大，在條件允許的情況下，我們盡可能將它設大Innodb_buffer_pool_pages_dataInnodb_buffer_pool_pages_data#Innodb已使用的緩存"頁Page"數(shù)量Innodb_buffer_pool_pages_totalInnodb全部緩存頁數(shù)量Innodb_buffer_pool_pages_free剩余緩存數(shù)量#頁面使用率計算公式result=Innodb_buffer_pool_pages_data/Innodb_buffer_pool_pages_total*100%val>95%則考慮增大innodb_buffer_pool_size，建議使用物理內(nèi)存的75%val<95%則考慮減小innodb_buffer_pool_size，建議設置為：Innodb_buffer_pool_pages_data*Innodb_page_size*1.05/(1024*1024*1024)Innodb_buffer_pool_pages_miscinnodbbufferpool緩存池中當前已經(jīng)被用作管理用途或hashindex而不能用作為普通數(shù)據(jù)頁的數(shù)目。單位是pageInnodb_buffer_pool_pages_dirtyinnodbbufferpool緩存池中臟頁的數(shù)目。單位是pageInnodb_buffer_pool_pages_flushedinnodbbufferpool緩存池中刷新頁請求的數(shù)目。單位是page。Innodb_buffer_pool_read_requests發(fā)生讀的總次數(shù)，也可以理解成邏輯讀Innodb_buffer_pool_reads發(fā)生從磁盤讀的次數(shù)InnodbBufferPool的Read命中率計算：(Innodb_buffer_pool_read_requests-Innodb_buffer_pool_reads)/Innodb_buffer_pool_read_requests*100%Innodb_buffer_pool_read_ahead后端預讀線程讀取到innodbbufferpool的頁的數(shù)目。單位是page。Innodb_buffer_pool_read_ahead_evicted預讀的頁數(shù)，但是沒有被讀取就從緩沖池中被替換的頁的數(shù)量，一般用來判斷預讀的效率。其它參數(shù)innodb_thread_concurrency#innodb_thread_concurrency#設置innodb線程的并發(fā)數(shù)，默認值為0表示不被限制，若要設置則與服務器的CPU核心數(shù)相同或是CPU的核心數(shù)的2倍。showglobalVARIABLESlike'innodb_thread_concurrency';innodb_write_io_threadsinnodb_read_io_threadsinnodb_purge_threads#innodb_purge_threads當事務成功提交后，事務所關聯(lián)的undolog已經(jīng)不再需要，故需要使用回收線程去回收，回收線程的數(shù)量默認為1個，建議修改為cpu核數(shù)innodb_purge_threads=8innodb_flush_log_at_trx_commit#innodb_flush_log_at_trx_commit#在事務控制中,存在"事務區(qū)"來保證事務完整性,在事務提交以后,這些事務區(qū)的數(shù)據(jù)會寫入到硬盤上,同時事務操作日志(log)也需要向硬盤中寫入.這個參數(shù)就是用來控制何時寫日志數(shù)據(jù)的.#0：logbuffer將每秒一次地寫入logfile中，并且logfile的flush(刷到磁盤)操作同時進行。該模式下在事務提交的時候，不會主動觸發(fā)寫入磁盤的操作。#1：每次事務提交時MySQL都會把logbuffer的數(shù)據(jù)寫入logfile，并且flush(刷到磁盤)中去，該模式為系統(tǒng)默認。#2：每次事務提交時MySQL都會把logbuffer的數(shù)據(jù)寫入logfile，但是flush(刷到磁盤)操作并不會同時進行。該模式下，MySQL會每秒執(zhí)行一次flush(刷到磁盤)操作。#三者比較#當設置為0，該模式速度最快，但不太安全，mysqld進程的崩潰會導致上一秒鐘所有事務數(shù)據(jù)的丟失。#當設置為1，該模式是最安全的，但也是最慢的一種方式。在mysqld服務崩潰或者服務器主機crash的情況下，binarylog只有可能丟失最多一個語句或者一個事務。。#當設置為2，該模式速度較快，也比0安全，只有在操作系統(tǒng)崩潰或者系統(tǒng)斷電的情況下，上一秒鐘所有事務數(shù)據(jù)才可能丟失。#實際測試發(fā)現(xiàn)，該值對插入數(shù)據(jù)的速度影響非常大，設置為2時插入10000條記錄只需要兩秒，設置為0時只需要一秒，設置為1時，則需要229秒。因此，MySQL手冊也建議盡量將插入操作合并成一個事務，這樣可以大幅度提高速度。innodb_lock_wait_timeout#innodb_lock_wait_timeout鎖等待超時innodb_lock_wait_timeout=30sinnodb_file_per_table#innodb_file_per_table=1#設置獨立表空間文件xxx.ibdinnodb_doublewrite#innodb_doublewrite雙寫操作#同一份數(shù)據(jù)寫入兩次,保證數(shù)據(jù)存在一個副本,預防數(shù)據(jù)因為介質(zhì)問題產(chǎn)生丟失showglobalVARIABLESlike'innodb_doublewrite';日志優(yōu)化binlog日志showvariableslike'%binlog%';binlog_cache_size“binlog_cache_size"：在事務過程中容納二進制日志SQL語句的緩存大小。二進制日志緩存是服務器支持事務存儲引擎并且服務器啟用了二進制日志(—log-bin選項)的前提下為每個客戶端分配的內(nèi)存，注意，是每個Client都可以分配設置大小的binlogcache空間。如果讀者朋友的系統(tǒng)中經(jīng)常會出現(xiàn)多語句事務的話，可以嘗試增加該值的大小，以獲得更有的性能。當然，我們可以通過MySQL的以下兩個狀態(tài)變量來判斷當前的binlog_cache_size的狀況：Binlog_cache_use和Binlog_cache_disk_use。max_binlog_cache_size“max_binlog_cache_size”：和"binlog_cache_size"相對應，但是所代表的是binlog能夠使用的最大cache內(nèi)存大小。當我們執(zhí)行多語句事務的時候，max_binlog_cache_size如果不夠大的話，系統(tǒng)可能會報出“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”的錯誤。max_binlog_size“max_binlog_size”：Binlog日志最大值，一般來說設置為512M或者1G，但不能超過1G。該大小并不能非常嚴格控制Binlog大小，尤其是當?shù)竭_Binlog比較靠近尾部而又遇到一個較大事務的時候，系統(tǒng)為了保證事務的完整性，不可能做切換日志的動作，只能將該事務的所有SQL都記錄進入當前日志，直到該事務結束。這一點和Oracle的Redo日志有點不一樣，因為Oracle的Redo日志所記錄的是數(shù)據(jù)文件的物理位置的變化，而且里面同時記錄了Redo和Undo相關的信息，所以同一個事務是否在一個日志中對Oracle來說并不關鍵。而MySQL在Binlog中所記錄的是數(shù)據(jù)庫邏輯變化信息，MySQL稱之為Event，實際上就是帶來數(shù)據(jù)庫變化的DML之類的Query語句。sync_binlog“sync_binlog”：這個參數(shù)是對于MySQL系統(tǒng)來說是至關重要的，他不僅影響到Binlog對MySQL所帶來的性能損耗，而且還影響到MySQL中數(shù)據(jù)的完整性。對于“sync_binlog”參數(shù)的各種設置的說明如下：●sync_binlog=0，當事務提交之后，MySQL不做fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤，而讓Filesystem自行決定什么時候來做同步，或者cache滿了之后才同步到磁盤?！駍ync_binlog=n，當每進行n次事務提交之后，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數(shù)據(jù)強制寫入磁盤。事務區(qū)日志我們可以通過如下查詢來檢測mysql中的buffer寫情況showstatuslike'innodb_log%';該值往往與innodb_flush_log_at_trx_commit設置有關，通常我們認為物理寫越少越好復制優(yōu)化MySQL中Binlog的產(chǎn)生量是沒辦法改變的，只要我們的Query改變了數(shù)據(jù)庫中的數(shù)據(jù)，那么就必須將該Query所對應的Event記錄到Binlog中。那我們是不是就沒有辦法優(yōu)化復制了呢？當然不是，在MySQL復制環(huán)境中，實際上是是有8個參數(shù)可以讓我們控制需要復制或者需要忽略而不進行復制的DB或者Table的，分別為：●Binlog_Do_DB：設定哪些數(shù)據(jù)庫（Schema）需要記錄Binlog；●Binlog_Ignore_DB：設定哪些數(shù)據(jù)庫（Schema）不要記錄Binlog；●Replicate_Do_DB：設定需要復制的數(shù)據(jù)庫（Schema），多個DB用逗號（“,”）分隔；●Replicate_Ignore_DB：設定可以忽略的數(shù)據(jù)庫（Schema）；●Replicate_Do_Table：設定需要復制的Table；●Replicate_Ignore_Table：設定可以忽略的Table；●Replicate_Wild_Do_Table：功能同Replicate_Do_Table，但可以帶通配符來進行設置；●Replicate_Wild_Ignore_Table：功能同Replicate_Ignore_Table，可帶通配符設置；實際上，上面這八個參數(shù)中的前面兩個是設置在Master端的，而后面六個參數(shù)則是設置在Slave端的。雖然前面兩個參數(shù)和后面六個參數(shù)在功能上并沒有非常直接的關系，但是對于優(yōu)化MySQL的Replication來說都可以啟到相似的功能。當然也有一定的區(qū)別，其主要區(qū)別如下：●如果在Master端設置前面兩個參數(shù)，不僅僅會讓Master端的Binlog記錄所帶來的IO量減少，還會讓Master端的IO線程就可以減少Binlog的讀取量，傳遞給Slave端的IO線程的Binlog量自然就會較少。這樣做的好處是可以減少網(wǎng)絡IO，減少Slave端IO線程的IO量，減少Slave端的SQL線程的工作量，從而最大幅度的優(yōu)化復制性能。當然，在Master端設置也存在一定的弊端，因為MySQL的判斷是否需要復制某個Event不是根據(jù)產(chǎn)生該Event的Query所更改的數(shù)據(jù)所在的DB，而是根據(jù)執(zhí)行Query時刻所在的默認Schema，也就是我們登錄時候指定的DB或者運行“USEDATABASE”中所指定的DB。只有當前默認DB和配置中所設定的DB完全吻合的時候IO線程才會將該Event讀取給Slave的IO線程。所以如果在系統(tǒng)中出現(xiàn)在默認DB和設定需要復制的DB不一樣的情況下改變了需要復制的DB中某個Table的數(shù)據(jù)的時候，該Event是不會被復制到Slave中去的，這樣就會造成Slave端的數(shù)據(jù)和Master的數(shù)據(jù)不一致的情況出現(xiàn)。同樣，如果在默認Schema下更改了不需要復制的Schema中的數(shù)據(jù)，則會被復制到Slave端，當Slave端并沒有該Schema的時候，則會造成復制出錯而停止；●而如果是在Slave端設置后面的六個參數(shù)，在性能優(yōu)化方面可能比在Master端要稍微遜色一點，因為不管是需要還是不需要復制的Event都被會被IO線程讀取到Slave端，這樣不僅僅增加了網(wǎng)絡IO量，也給Slave端的IO線程增加了RelayLog的寫入量。但是仍然可以減少Slave的SQL線程在Slave端的日志應用量。雖然性能方面稍有遜色，但是在Slave端設置復制過濾機制，可以保證不會出現(xiàn)因為默認Schema的問題而造成Slave和Master數(shù)據(jù)不一致或者復制出錯的問題。事務隔離READUNCOMMITTED常被成為DirtyReads（臟讀），可以說是事務上的最低隔離級別：在普通的非鎖定模式下SELECT的執(zhí)行使我們看到的數(shù)據(jù)可能并不是查詢發(fā)起時間點的數(shù)據(jù)，因而在這個隔離度下是非ConsistentReads（一致性讀）；READCOMMITTED這個事務隔離級別有些類似Oracle數(shù)據(jù)庫默認的隔離級。屬于語句級別的隔離，如通過SELECT...FORUPDATE和SELECT...LOCKINSHAREMODE來執(zhí)行的請求僅僅鎖定索引記錄，而不鎖定之前的間隙，因而允許在鎖定的記錄后自由地插入新記錄。當然，這與Innodb的鎖定實現(xiàn)機制有關。如果我們的Query可以很準確的通過索引定位到需要鎖定的記錄，則僅僅只需要鎖定相關的索引記錄，而不需要鎖定該索引之前的間隙。但如果我們的Query通過索引檢索的時候無法通過索引準確定位到需要鎖定的記錄，或者是一個基于范圍的查詢，InnoDB就必須設置next-key或gaplocks來阻塞其它用戶對范圍內(nèi)的空隙插入。ConsistentReads的實現(xiàn)機制與Oracle基本類似：每一個ConsistentRead，甚至是同一個事務中的，均設置并作為它自己的最新快照。這一隔離級別下，不會出現(xiàn)DirtyRead，但是可能出現(xiàn)Non-RepeatableReads(不可重復讀)和PhantomReads（幻讀）。REPEATABLEREADREPEATABLEREAD隔離級別是InnoDB默認的事務隔離級。SELECT...FORUPDATE,SELECT...LOCKINSHAREMODE,UPDATE,和DELETE，這些以唯一條件搜索唯一索引的，只鎖定所找到的索引記錄，而不鎖定該索引之前的間隙。否則這些操作將使用next-key鎖定，以next-key和gaplocks鎖定找到的索引范圍，并阻塞其它用戶的新建插入。在ConsistentReads中，與前一個隔離級相比這是一個重要的差別：在這一級中，同一事務中所有的ConsistentReads均讀取第一次讀取時已確定的快照。這個約定就意味著如果在同一事務中發(fā)出幾個無格式(plain)的SELECTs，這些SELECT的相互關系是一致的。在REPEATABLEREAD隔離級別下，不會出現(xiàn)DirtyReads，也不會出現(xiàn)Non-RepeatableReads，但是仍然存在PhantomReads的可能性。SERIALIZABLESERIALIZABLE隔離級別是標準事務隔離級別中的最高級別。設置為SERIALIZABLE隔離級別之后，在事務中的任何時候所看到的數(shù)據(jù)都是事務啟動時刻的狀態(tài)，不論在這期間有沒有其他事務已經(jīng)修改了某些數(shù)據(jù)并提交。所以，SERIALIZABLE事務隔離級別下，PhantomReads也不會出現(xiàn)。綜合建議以上四種事務隔離級別實際上就是ANSI/ISOSQL92標準所定義的四種隔離級別，Innodb全部都為我們實現(xiàn)了。對于高并發(fā)應用來說，為了盡可能保證數(shù)據(jù)的一致性，避免并發(fā)可能帶來的數(shù)據(jù)不一致問題，自然是事務隔離級別越高越好。但是，對于Innodb來說，所使用的事務隔離級別越高，實現(xiàn)復雜度自然就會更高，所需要做的事情也會更多，整體性能也就會更差。所以，我們需要分析自己應用系統(tǒng)的邏輯，選擇可以接受的最低事務隔離級別。以在保證數(shù)據(jù)安全一致性的同時達到最高的性能。雖然Innodb存儲引擎默認的事務隔離級別是REPEATABLEREAD，但實際上在我們大部分的應用場景下，都只需要READCOMMITED的事務隔離級別就可以滿足需求了。會話參數(shù)以下為64G內(nèi)存時，連接參數(shù)設置參考read_buffer_size=16Mread_rnd_buffer_size=32Msort_buffer_size=32Mjoin_buffer_size=128Mtmp_table_size=64Msort_buffer_size#sort_buffer_size每個需要排序的線程分配該大小的一個緩沖區(qū)。增加這值加速ORDERBY或GROUPBY操作sort_buffer_size是一個connection級的參數(shù)，在每個connection（session）第一次需要使用這個buffer的時候，一次性分配設置的內(nèi)存。sort_buffer_size：并不是越大越好，由于是connection級的參數(shù)，過大的設置+高并發(fā)可能會耗盡系統(tǒng)的內(nèi)存資源。例如：500個連接將會消耗500*sort_buffer_size(2M)=1G 其它參數(shù)參考后面的樣例提供常用性能監(jiān)控查詢總視圖showglobalstatuslike'Com_select%';showglobalstatuslike'Com_insert%';showglobalstatuslike'Com_update%';showglobalstatuslike'Com_delete%';showglobalstatuslike'Connections%';showglobalstatuslike'Uptime%';showglobalstatuslike'Slow_queries%';通過如上參數(shù)我們可以了解到當前數(shù)據(jù)庫主要是以插入更新為主還是查找為主，以及各個SQL語句執(zhí)行的比例，知道這些情況后，可以對當前數(shù)據(jù)庫設計做一個大概的了解，方便后續(xù)對數(shù)據(jù)進行一個優(yōu)化查詢連接列表查詢select*from`performance_schema`.hosts也可以通過當前進程查詢：select SUBSTRING_INDEX(host,':',1)ashostip, count(*)numfrom information_cesslistgroupby hostip;查詢長時間連接select *from information_cesslistwhere Command!='Sleep'orderby Timedesc;查詢慢SQL開啟慢查詢showvariableslike'slow_query%';showvariableslike'long_query_time';該命令主要查看系統(tǒng)慢查詢的資料，什么是慢查詢，慢查詢就是mysql可以設置一個時間數(shù)，當一個sql語句執(zhí)行時間超過這個時間段，則認為該條sql語句是慢查詢語句，然后我們可以針對該sql進行優(yōu)化。setglobalslow_query_log='ON';setglobalslow_query_log_file='/project/slow.log';setgloballong_query_time=1;注意：以上命令只對新連接生效統(tǒng)計排名mysqldumpslow-st-t100/home/teledb/data/data_8801/mysql_data8801/logs/73_8801/slow_query_2021_12_30_00_00_03.log參數(shù)說明：-s:排序方式按鎖的時間l、返回的記錄數(shù)r、查詢的時間t、記錄的次數(shù)c,倒序的話可以加r-t:查詢前多少條記錄-g:支持正則表達式,以及忽略大小寫在這里順便說下explain吧explain用來分析mysql查詢結構的主要關注四個參數(shù)值：type、key、rows、extras訪問類型type:al最差,ref,eq_ref居中,null最好all->index->range->ref->eq_ref->const或system->null有無使用索引key:key為空沒有使用索引找到所需記錄要讀取的行數(shù)：rows,rows值越小越好查詢分析開啟查詢showvariableslike'general_log';showvariableslike'general_log_file';showvariableslike'log_output';setglobalgeneral_log=on;setglobalgeneral_log_file='tmp/general.lg';setgloballog_output='table';setgloballog_output='file';查看各表統(tǒng)計信息SELECT table_name, table_rowsFROM information_schema.tablesawhere a.TABLE_SCHEMA='custdb_ah_1'orderby table_rowsdesc分析表執(zhí)行計劃explainselect*fromcustomer;查詢當前進程查詢進程showfullprocesslist主要狀態(tài)這個命令中最關鍵的就是state列，mysql列出的狀態(tài)主要有以下幾種：Checkingtable正在檢查數(shù)據(jù)表（這是自動的）。Closingtables正在將表中修改的數(shù)據(jù)刷新到磁盤中，同時正在關閉已經(jīng)用完的表。這是一個很快的操作，如果不是這樣的話，就應該確認磁盤空間是否已經(jīng)滿了或者磁盤是否正處于重負中。ConnectOut復制從服務器正在連接主服務器。Copyingtotmptableondisk由于臨時結果集大于tmp_table_size，正在將臨時表從內(nèi)存存儲轉(zhuǎn)為磁盤存儲以此節(jié)省內(nèi)存。Creatingtmptable正在創(chuàng)建臨時表以存放部分查詢結果。deletingfrommaintable服務器正在執(zhí)行多表刪除中的第一部分，剛刪除第一個表。deletingfromreferencetables服務器正在執(zhí)行多表刪除中的第二部分，正在刪除其他表的記錄。Flushingtables正在執(zhí)行FLUSHTABLES，等待其他線程關閉數(shù)據(jù)表。Killed發(fā)送了一個kill請求給某線程，那么這個線程將會檢查kill標志位，同時會放棄下一個kill請求。MySQL會在每次的主循環(huán)中檢查kill標志位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那么kill請求會在鎖釋放時馬上生效。Locked被其他查詢鎖住了。Sendingdata正在處理SELECT查詢的記錄，同時正在把結果發(fā)送給客戶端。Sortingforgroup正在為GROUPBY做排序。Sortingfororder正在為ORDERBY做排序。Openingtables這個過程應該會很快，除非受到其他因素的干擾。例如，在執(zhí)ALTERTABLE或LOCKTABLE語句行完以前，數(shù)據(jù)表無法被其他線程打開。正嘗試打開一個表。Removingduplicates正在執(zhí)行一個SELECTDISTINCT方式的查詢，但是MySQL無法在前一個階段優(yōu)化掉那些重復的記錄。因此，MySQL需要再次去掉重復的記錄，然后再把結果發(fā)送給客戶端。Reopentable獲得了對一個表的鎖，但是必須在表結構修改之后才能獲得這個鎖。已經(jīng)釋放鎖，關閉數(shù)據(jù)表，正嘗試重新打開數(shù)據(jù)表。Repairbysorting修復指令正在排序以創(chuàng)建索引。Repairwithkeycache修復指令正在利用索引緩存一個一個地創(chuàng)建新索引。它會比Repairbysorting慢些。Searchingrowsforupdate正在講符合條件的記錄找出來以備更新。它必須在UPDATE要修改相關的記錄之前就完成了。Sleeping正在等待客戶端發(fā)送新請求.Systemlock正在等待取得一個外部的系統(tǒng)鎖。如果當前沒有運行多個mysqld服務器同時請求同一個表，那么可以通過增加--skip-external-locking參數(shù)來禁止外部系統(tǒng)鎖。UpgradinglockINSERTDELAYED正在嘗試取得一個鎖表以插入新記錄。Updating正在搜索匹配的記錄，并且修改它們。UserLock正在等待GET_LOCK()。Waitingfortables該線程得到通知，數(shù)據(jù)表結構已經(jīng)被修改了，需要重新打開數(shù)據(jù)表以取得新的結構。然后，為了能的重新打開數(shù)據(jù)表，必須等到所有其他線程關閉這個表。以下幾種情況下會產(chǎn)生這個通知：FLUSHTABLEStbl_name,ALTERTABLE,RENAMETABLE,REPAIRTABLE,ANALYZETABLE,或OPTIMIZETABLE。waitingforhandlerinsertINSERTDELAYED已經(jīng)處理完了所有待處理的插入操作，正在等待新的請求。狀態(tài)查詢showstatus下面我們看幾個常用的帶選項的命令查詢當前MySQL本次啟動后的運行統(tǒng)計時間showstatuslike'uptime';查看本次MySQL啟動后執(zhí)行的select語句的次數(shù)showstatuslike'com_select';查看本次MySQL啟動后執(zhí)行insert語句的次數(shù)show[global]statuslike'com_insert';查看本次MySQL啟動后執(zhí)行update語句的次數(shù)show[global]statuslike'com_update';查看本次MySQL啟動后執(zhí)行delete語句的次數(shù)show[global]statuslike'com_delete';查看MySQL服務器的線程信息showstatuslike'Thread_%';查看試圖連接到MySQL(不管是否連接成功)的連接數(shù)showstatuslike'connections';查看線程緩存內(nèi)的線程的數(shù)量showstatuslike'threads_cached';查看立即獲得的表的鎖的次數(shù)showstatuslike'table_locks_immediate';查看不能立即獲得的表的鎖的次數(shù)。如果該值較高，并且有性能問題，你應首先優(yōu)化查詢，然后拆分表或使用復制showstatuslike'table_locks_waited';查看查詢時間超過long_query_time秒的查詢的個數(shù)showstatuslike'slow_queries';鎖監(jiān)控查詢查詢鎖表情況showstatuslike'Table_locks_%';Table_locks_immediate指的是能夠立即獲得表級鎖的次數(shù)Table_locks_waited指的是不能立即獲取表級鎖而需要等待的次數(shù)，如果數(shù)量大，說明鎖等待多，有鎖爭用情況查詢當前事務鎖查詢當前鎖表showOPENTABLESwhereIn_use>0;查詢被鎖事務SELECT*FROMinformation_schema.INNODB_TRXWHEREtrx_state='LOCKWAIT';查詢到鎖源select c.*from information_schema.INNODB_LOCK_WAITSa, information_schema.innodb_trxb,information_schema.`PROCESSLIST`cwhere a.blocking_trx_id=b.trx_id andb.trx_mysql_thread_id=c.id anda.requesting_trx_id=21734679查詢鎖源sql語句SELECT*FROMperformance_schema.`events_statements_current`WHEREthread_idin(selectm.THREAD_IDfrom`performance_schema`.threadsmwherem.PROCESSLIST_ID=24);SELECT*FROMperformance_schema.`events_statements_history`WHEREthread_idin(selectm.THREAD_IDfrom`performance_schema`.threadsmwherem.PROCESSLIST_ID=24);快速方法查看事務鎖SHOWSTATUSLIKE'innodb_row_lock%';快速查詢鎖select r.trx_isolation_level, r.trx_idwaiting_trx_id, r.trx_mysql_thread_idwaiting_trx_thread, r.trx_statewaiting_trx_state, lr.lock_modewaiting_trx_lock_mode, lr.lock_typewaiting_trx_lock_type, lr.lock_tablewaiting_trx_lock_table, lr.lock_indexwaiting_trx_lock_index, r.trx_querywaiting_trx_query, b.trx_idblocking_trx_id, b.trx_mysql_thread_idblocking_trx_thread, b.trx_stateblocking_trx_state, lb.lock_modeblocking_trx_lock_mode, lb.lock_typeblocking_trx_lock_type, lb.lock_tableblocking_trx_lock_table, lb.lock_indexblocking_trx_lock_index, b.trx_queryblocking_queryfrom information_schema.innodb_lock_waitsw innerjoininformation_schema.innodb_trxbonb.trx_id=w.blocking_trx_id innerjoininformation_schema.innodb_trxronr.trx_id=w.requesting_trx_id innerjoininformation_schema.innodb_lockslbonlb.lock_trx_id=w.blocking_trx_id innerjoininformation_schema.innodb_lockslronlr.lock_trx_id=w.requesting_trx_idperformance_schema開啟說明--查看performance_schema的屬性，ON表示開啟SHOWVARIABLESLIKE'performance_schema';如果要關閉性能模式，不能用命令關閉，需要修改配置文件mysql.iniperformance_schema=ON表分類說明-語句事件記錄表，這些表記錄了語句事件信息，當前語句事件表events_statements_current、歷史語句事件表events_statements_history和長語句歷史事件表events_statements_history_long、以及聚合后的摘要表summary，其中，summary表還可以根據(jù)帳號(account)，主機(host)，程序(program)，線程(thread)，用戶(user)和全局(global)再進行細分)showtableslike'%statement%';--等待事件記錄表，與語句事件類型的相關記錄表類似：showtableslike'%wait%';--階段事件記錄表，記錄語句執(zhí)行的階段事件的表showtableslike'%stage%';--事務事件記錄表，記錄事務相關的事件的表showtableslike'%transaction%';--監(jiān)控文件系統(tǒng)層調(diào)用的表showtableslike'%file%';--監(jiān)視內(nèi)存使用的表showtableslike'%memory%';--動態(tài)對performance_schema進行配置的配置表showtableslike'%setup%';簡單使用數(shù)據(jù)信息采集和保存性能數(shù)據(jù)項目都是需要設置的，默認不會全部打開。列1：打開等待事件的采集器配置項開關，需要修改setup_instruments配置表中對應的采集器配置項UPDATEsetup_instrumentsSETENABLED='YES',TIMED='YES'wherenamelike'wait%';列2：打開等待事件的保存表配置開關，修改setup_consumers配置表中對應的配置項UPDATEsetup_consumersSETENABLED='YES'wherenamelike'%wait%';當配置完成之后可以查看當前server正在做什么，可以通過查詢events_waits_current表來得知，該表中每個線程只包含一行數(shù)據(jù)，用于顯示每個線程的最新監(jiān)視事件系統(tǒng)變量showvariableslike'%performance_schema%';--重要的屬性解釋performance_schema=ON/*控制performance_schema功能的開關，要使用MySQL的performance_schema，需要在mysqld啟動時啟用，以啟用事件收集功能該參數(shù)在5.7.x之前支持performance_schema的版本中默認關閉，5.7.x版本開始默認開啟注意：如果mysqld在初始化performance_schema時發(fā)現(xiàn)無法分配任何相關的內(nèi)部緩沖區(qū)，則performance_schema將自動禁用，并將performance_schema設置為OFF*/performance_schema_digests_size=10000/*控制events_statements_summary_by_digest表中的最大行數(shù)。如果產(chǎn)生的語句摘要信息超過此最大值，便無法繼續(xù)存入該表，此時performance_schema會增加狀態(tài)變量*/performance_schema_events_statements_history_long_size=10000/*控制events_statements_history_long表中的最大行數(shù)，該參數(shù)控制所有會話在events_statements_history_long表中能夠存放的總事件記錄數(shù)，超過這個限制之后，最早的記錄將被覆蓋全局變量，只讀變量，整型值，5.6.3版本引入*5.6.x版本中，5.6.5及其之前的版本默認為10000，5.6.6及其之后的版本默認值為-1，通常情況下，自動計算的值都是10000*5.7.x版本中，默認值為-1，通常情況下，自動計算的值都是10000*/performance_schema_events_statements_history_size=10/*控制events_statements_history表中單個線程（會話）的最大行數(shù)，該參數(shù)控制單個會話在events_statements_history表中能夠存放的事件記錄數(shù)，超過這個限制之后，單個會話最早的記錄將被覆蓋全局變量，只讀變量，整型值，5.6.3版本引入*5.6.x版本中，5.6.5及其之前的版本默認為10，5.6.6及其之后的版本默認值為-1，通常情況下，自動計算的值都是10*5.7.x版本中，默認值為-1，通常情況下，自動計算的值都是10除了statement(語句)事件之外，wait(等待)事件、state(階段)事件、transaction(事務)事件，他們與statement事件一樣都有三個參數(shù)分別進行存儲限制配置，有興趣的同學自行研究，這里不再贅述*/performance_schema_max_digest_length=1024/*用于控制標準化形式的SQL語句文本在存入performance_schema時的限制長度，該變量與max_digest_length變量相關(max_digest_length變量含義請自行查閱相關資料)全局變量，只讀變量，默認值1024字節(jié)，整型值，取值范圍0~1048576*/performance_schema_max_sql_text_length=1024/*控制存入events_statements_current，events_statements_history和events_statements_history_long語句事件表中的SQL_TEXT列的最大SQL長度字節(jié)數(shù)。超出系統(tǒng)變量performance_schema_max_sql_text_length的部分將被丟棄，不會記錄，一般情況下不需要調(diào)整該參數(shù)，除非被截斷的部分與其他SQL比起來有很大差異全局變量，只讀變量，整型值，默認值為1024字節(jié)，取值范圍為0~1048576，5.7.6版本引入降低系統(tǒng)變量performance_schema_max_sql_text_length值可以減少內(nèi)存使用，但如果匯總的SQL中，被截斷部分有較大差異，會導致沒有辦法再對這些有較大差異的SQL進行區(qū)分。增加該系統(tǒng)變量值會增加內(nèi)存使用，但對于匯總SQL來講可以更精準地區(qū)分不同的部分。*/啟動選項performance_schema_consumer_events_statements_current=TRUE是否在mysqlserver啟動時就開啟events_statements_current表的記錄功能(該表記錄當前的語句事件信息)，啟動之后也可以在setup_consumers表中使用UPDATE語句進行動態(tài)更新setup_consumers配置表中的events_statements_current配置項，默認值為TRUEperformance_schema_consumer_events_statements_history=TRUE與performance_schema_consumer_events_statements_current選項類似，但該選項是用于配置是否記錄語句事件短歷史信息，默認為TRUEperformance_schema_consumer_events_stages_history_long=FALSE與performance_schema_consumer_events_statements_current選項類似，但該選項是用于配置是否記錄語句事件長歷史信息，默認為FALSE除了statement(語句)事件之外，還支持：wait(等待)事件、state(階段)事件、transaction(事務)事件，他們與statement事件一樣都有三個啟動項分別進行配置，但這些等待事件默認未啟用，如果需要在MySQLServer啟動時一同啟動，則通常需要寫進f配置文件中performance_schema_consumer_global_instrumentation=TRUE是否在MySQLServer啟動時就開啟全局表（如：mutex_instances、rwlock_instances、cond_instances、file_instances、users、hostsaccounts、socket_summary_by_event_name、file_summary_by_instance等大部分的全局對象計數(shù)統(tǒng)計和事件匯總統(tǒng)計信息表）的記錄功能，啟動之后也可以在setup_consumers表中使用UPDATE語句進行動態(tài)更新全局配置項默認值為TRUEperformance_schema_consumer_statements_digest=TRUE是否在MySQLServer啟動時就開啟events_statements_summary_by_digest表的記錄功能，啟動之后也可以在setup_consumers表中使用UPDATE語句進行動態(tài)更新digest配置項默認值為TRUEperformance_schema_consumer_thread_instrumentation=TRUE是否在MySQLServer啟動時就開啟events_xxx_summary_by_yyy_by_event_name表的記錄功能，啟動之后也可以在setup_consumers表中使用UPDATE語句進行動態(tài)更新線程配置項默認值為TRUEperformance_schema_instrument[=name]是否在MySQLServer啟動時就啟用某些采集器，由于instruments配置項多達數(shù)千個，所以該配置項支持key-value模式，還支持%號進行通配等，如下:重要配置表performance_timers/*performance_timers表中記錄了server中有哪些可用的事件計時器字段解釋： timer_name:表示可用計時器名稱，CYCLE是基于CPU周期計數(shù)器的定時器 timer_frequency:表示每秒鐘對應的計時器單位的數(shù)量,CYCLE計時器的換算值與CPU的頻率相關、 timer_resolution:計時器精度值，表示在每個計時器被調(diào)用時額外增加的值 timer_overhead:表示在使用定時器獲取事件時開銷的最小周期值*/select*fromperformance_timers;setup_timers/*setup_timers表中記錄當前使用的事件計時器信息字段解釋： name:計時器類型，對應某個事件類別 timer_name:計時器類型名稱*/select*fromsetup_timers;setup_consumers/*setup_consumers表中列出了consumers可配置列表項字段解釋： NAME：consumers配置名稱 ENABLED：consumers是否啟用，有效值為YES或NO，此列可以使用UPDATE語句修改。*/select*fromsetup_consumers;setup_instruments/*setup_instruments表列出了instruments列表配置項，即代表了哪些事件支持被收集：字段解釋： NAME：instruments名稱，instruments名稱可能具有多個部分并形成層次結構 ENABLED：instrumetns是否啟用，有效值為YES或NO，此列可以使用UPDATE語句修改。如果設置為NO，則這個instruments不會被執(zhí)行，不會產(chǎn)生任何的事件信息 TIMED：instruments是否收集時間信息，有效值為YES或NO，此列可以使用UPDATE語句修改，如果設置為NO，則這個instruments不會收集時間信息*/SELECT*FROMsetup_instruments;setup_actor/*setup_actors表的初始內(nèi)容是匹配任何用戶和主機，因此對于所有前臺線程，默認情況下啟用監(jiān)視和歷史事件收集功能字段解釋： HOST：與grant語句類似的主機名，一個具體的字符串名字，或使用“％”表示“任何主機” USER：一個具體的字符串名稱，或使用“％”表示“任何用戶” ROLE：當前未使用，MySQL8.0中才啟用角色功能 ENABLED：是否啟用與HOST，USER，ROLE匹配的前臺線程的監(jiān)控功能，有效值為：YES或NO HISTORY：是否啟用與HOST，USER，ROLE匹配的前臺線程的歷史事件記錄功能，有效值為：YES或NO*/SELE