MySqL線上status做出適當優化


 優化的一些命令:

mysql> show global staus;   //這個是顯示所有的狀態的命令;   1、慢查詢 mysql> show variables like '%slow%'; +---------------------+-----------------------------------+ | Variable_name       | Value                             | +---------------------+-----------------------------------+ | log_slow_queries    | ON                                | | slow_launch_time    | 2                                 | | slow_query_log      | ON                                | | slow_query_log_file | /var/lib/mysql/localhost-slow.log | +---------------------+-----------------------------------+ 4 rows in set (0.00 sec) 顯示出慢查詢限制時間為2秒,慢查詢日志文件所在的目錄   mysql> show global status like '%slow%'; +---------------------+-------+ | Variable_name       | Value | +---------------------+-------+ | Slow_launch_threads | 0     | | Slow_queries        | 38    | +---------------------+-------+ 2 rows in set (0.00 sec)   打開慢查詢日志可能會對系統有一點點的影響,如果你的MySQL是主從復制結構,可以考慮打開其中一台從服務器的慢查詢日志,這樣既可以監控慢查詢,對系統性能的影響也會很小。另外,可用MySQL自帶的命令mysqldumpslow進行查詢。比如,下面的命令可以查詢出訪問次數最多的20個SQL語句 mysqldumpslow -s c -t 20 host-slow.log   2、連接數 如果經常出現MySQL:ERROR 1040:Too manyconnections 的情況,一種情況是訪問量確實很高,MySQL服務器扛不住了,這個時候要考慮增加從服務器分散讀壓力。另外一種情況是MySQL配置文件中max_connections的值過小。所用命令如下: mysql> show variables like 'max_connections'; +-----------------+-------+ | Variable_name   | Value | +-----------------+-------+ | max_connections | 800   | +-----------------+-------+ 1 row in set (0.00 sec) 這台MySQL服務器的最大連接數是800,然后再查詢一下該服務器響應的最大連數: mysql> show global status like 'Max_used_connections'; +----------------------+-------+ | Variable_name        | Value | +----------------------+-------+ | Max_used_connections | 88    | +----------------------+-------+ 1 row in set (0.00 sec)   MySQL服務器的最大連接數是88,沒有達到服務器連接數的上限800,應該不會出現1040錯誤。比較理想的設置是: Max_used_connections / max_connections * 100% 這個數值在85%左右 最大連接數占上限連接數和85%左右,如果發現比例在10%以下,則說明MySQL服務器連接數的上限設置的過高了。   3、key_buffer_size key_buffer_size是設置MyISAM表緩存空間的大小,此參數對MyISAM表性能影響最大。   mysql> show variables like 'key_buffer_size';   +-----------------+-----------+ | Variable_name   | Value     | +-----------------+-----------+ | key_buffer_size | 268435456 | +-----------------+-----------+ 1 row in set (0.00 sec) 從上面的配置可以看出,分配了256MB內存給key_buffer_size.下面再來看一下它的使用情況: mysql> show global status like 'key_read%'; +-------------------+-------+ | Variable_name     | Value | +-------------------+-------+ | Key_read_requests | 15319 | | Key_reads         | 3     | +-------------------+-------+ 2 rows in set (0.00 sec) 一共有15319個索引讀取請求,有3個請求在內存中沒找到,直接從硬盤讀取索引,計算索引未命中緩存的的概率: Key_cache_miss_rate = Key_reads / Key_read_requests * 100% 比如上面的數據,Key_cache_miss_rate 為0.01958%,這個未命中的概率很小,效果上已經很好了,Key_cache_miss_rate在0.1%(即每1000個請求有一個直接讀硬盤)以下都很好,如果Key_cache_miss_rate在0.01%以下的話,則說明key_buffer_size分配得過多,可以適當減少。 MySQL服務器還提供了key_blocks_*參數,如下所示:   mysql> show global status like 'key_blocks_u%'; +-------------------+--------+ | Variable_name     | Value  | +-------------------+--------+ | Key_blocks_unused | 6      | | Key_blocks_used   | 231957 | +-------------------+--------+ 2 rows in set (0.00 sec) Key_blocks_unused表示未使用的緩存簇(blocks)數,Key_blocks_used表示曾經用到的最大的blocks數。比如這台服務器,所有的緩存都用到了,要么增加key_buffer_size,要么就是過度索引,把緩存占滿了。比較理想的設置是: Key_blocks_used / (key_blocks_unused + Key_blocks_used) * 100% ==80%   4、臨時表   當執行語句時,關於已經被創造了的隱含臨時表的數量,我們可以用如下命令查詢其具體情況: mysql> show global status like 'created_tmp%'; +-------------------------+----------+ | Variable_name           | Value    | +-------------------------+----------+ | Created_tmp_disk_tables | 135      | | Created_tmp_files       | 5        | | Created_tmp_tables      | 37526111 | +-------------------------+----------+ 3 rows in set (0.00 sec)   每次創建臨時表時,Created_tmp_tables都會增加,如果是在磁盤上創建臨時表,Created_tmp_disk_tables也會增加。Created_tmp_files表示MySQL服務創建的臨時文件數,比較理想的配置是:Created_tmp_disk_tables / created_tmp_tables  * 100% <= 25% 比如上面的服務器created_tmp_disk_tables/Created_tmp_tables * 100% = 0.00035%,應該說是相當好了。我們再看一下MySQL服務器對臨時表的配置:   mysql> show variables where Variable_name in ('tmp_table_size','max_heap_table_size'); +---------------------+-----------+ | Variable_name       | Value     | +---------------------+-----------+ | max_heap_table_size | 67108864  | | tmp_table_size      | 268435456 | +---------------------+-----------+ 2 rows in set (0.00 sec) 只有64MB以下的臨時表才能放在內存中,超過的就會用到硬盤臨時表。   5、打開表的情況 Open_tables 表示打開表的數量,Open_tables表示打開過的表數量,我們可以用如下命令查看其具體情況: mysql> show global status like 'open%tables%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Open_tables   | 646   | | Opened_tables | 653   | +---------------+-------+ 如果Opened_tables數量過大,說明配置中table_cache(MySQL5.1.3之后這個值叫做table_open_cache)的值可能太小。我們查詢一下服務器table_cache值: mysql> show variables like 'table_open_cache'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | table_cache   | 1024  | +---------------+-------+ 比較合適的值為: Open_tables / Opened_tables * 100% >=85% Open_tables / table_cache * 100% <=95%   mysql> show variables like 'table_open_cache';+------------------+-------+| Variable_name    | Value |+------------------+-------+| table_open_cache | 1024  |+------------------+-------+1 row in set (0.00 sec)  6 進程使用情況 如果我們在MySQL服務器的配置文件中設置了thread_cache_size,當客戶端斷開之時,服務器處理此客戶請求的線程將會緩存起來以響應下一個客戶而不是銷毀(前提是緩存未達到上限)。Threads_created表示創建過的線程數,我們可以用如下命令查看: mysql> show global status like 'Thread%'; +-------------------+-------+ | Variable_name     | Value | +-------------------+-------+ | Threads_cached    | 59    | | Threads_connected | 44    | | Threads_created   | 138   | | Threads_running   | 1     | +-------------------+-------+ 如果發現Threads_created的值過大的話,表明MySQL服務器一直在創建線程,這也是比較耗費資源的,可以適當的增大配置文件中thread_cache_size的值。查詢服務器thread_cache_size配置,如下所示: mysql> show variables like 'thread_cache_size'; +-------------------+-------+ | Variable_name     | Value | +-------------------+-------+ | thread_cache_size | 64    | +-------------------+-------+ 示例中的MySQL服務器還是挺健康的。 如果運用命令:mysql> show full processlist; 顯示出大量的sending data 而且時間很長那就有可能是數據庫一直在創建進程,此時要增大thread_cache_size的值。   7、查詢緩存(query cache) 它主要涉及兩個參數,query_cache_size是設置MySQL的Query Cache大小,query_cache_type是設置使用查詢緩存的類型,我們可以用如下命令查看其具體情況: mysql>show global status like 'qcache%'; +-------------------------+----------+ | Variable_name           | Value    | +-------------------------+----------+ | Qcache_free_blocks      | 452      | | Qcache_free_memory      | 83214448 | | Qcache_hits             | 52902869 | | Qcache_inserts          | 1856039  | | Qcache_lowmem_prunes    | 305804   | | Qcache_not_cached       | 42944    | | Qcache_queries_in_cache | 80812    | | Qcache_total_blocks     | 162634   | +-------------------------+----------+ 8 rows in set (0.01 sec) MySQL查詢緩存變量的相關解釋如下。 Qcache_free_blocks:緩存中相鄰內存塊的個數。數目大說明可能有碎片。FLUSH QUERY CACHE 會對緩存中的碎片進行處理,從而得到一個空閑塊。 Qcache_free_memory:緩存中的空閑內存。 Qcache_hits:多少次命中。通過這個參數可以查看到Query Cache的基本效果。 Qcache_inserts:插入次數,每次插入一個查詢時就增加1.命中次數除以插入次數就是命中比率。 Qcache_lowmem_prunes:多少條Query因為內存不足而被清除出Query Cache 通過Qcache_lowmem_prunes和Qcache_free_memory相互結合,能夠更清楚地了解到系統中Query Cache的內存大小是否真的足夠,是否非常頻繁地出現因為內存不足而有Query被換出的情況。 Qcache_not_cached:不適合進行緩存的查詢數量,通常是由於這些查詢不是SELECT語句或者用了now()之類的函數。 Qcache_queries_in_cache:當前緩存的查詢(和響應)數量。 Qcache_total_blocks:緩存中塊的數量。 我們再查詢一下服務器上關於query_cache的配置命令如下: mysql>show variables like 'query_cache%'; +------------------------------+-----------+ | Variable_name                | Value     | +------------------------------+-----------+ | query_cache_limit            | 3145728   | | query_cache_min_res_unit     | 4096      | | query_cache_size             | 268435456 | | query_cache_type             | ON        | | query_cache_wlock_invalidate | OFF       | +------------------------------+-----------+ 5 rows in set (0.00 sec) 各字段的解釋如下: query_cache_limit:超過此大小的查詢將不緩存。 query_cache_min_res_unit:緩存塊的最小值。 query_cache_type:緩存類型,決定緩存什么樣的查詢,示例中表示不緩存select sql_no_cache查詢   query_cache_wlock_invalidate:表示當有其他客戶端正在對MyISAM表示進行寫操作時,讀請求是要等WRITE LOCK釋放資源后再查詢還是允許直接從Query Cache中讀取結果,默認為OFF(可以直接從Query Cache中取得結果)。   query_cache_min_res_unit 的配置是一柄“雙刃劍”,默認是4KB,設置的值大對大數據查詢有好處,但如果你的查詢都是小數據查詢,就容易造成內存碎片和浪費。 查詢緩存碎片率=Qcache_free_blocks / Qcache_total_blocks * 100% 如果查詢緩存碎片率超過20%,可以用FLUSH QUERY CACHE整理緩存碎片,或者試試減小query_cache_min_res_unit,如果你的查詢都是小數據量的話。 查詢緩存利用率=(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_inserts)/ Qcache_hits * 100% 示例服務器中的查詢緩存碎片率等於0.2779%,查詢緩存利用率等於61.5%,查詢緩存命中率等於96.49%,說明命中率還是挺高的,而且碎片很少。   8、排序使用情況 它表示系統中對數據進行排序時所使用的Buffer,我們可以用如下命令查看: mysql> show global status like 'sort%'; +-------------------+----------+ | Variable_name     | Value    | +-------------------+----------+ | Sort_merge_passes | 23       | | Sort_range        | 35536    | | Sort_rows         | 19732031 | | Sort_scan         | 46755    | +-------------------+----------+ 4 rows in set (0.06 sec) Sort_merge_passes包括如下步驟:MySQL首先會嘗試在內存中做排序,使用的內存大小由系統變量sort_buffer_size來決定,如果它不夠大則把所有的記錄都讀到內存中,而MySQL則會把每次在內存中排序的結果存到臨時文件中,等MySQL找到所有記錄之后,再把臨時文件中的記錄做一次排序。這次再排序就會增加sort_merge_passes。實際上,MySQL會用另一個臨時文件來存儲再次排序的結果,所以我們通常會看到sort_merge_passes增加的數值是建立臨時文件數的兩倍。因為用到了臨時文件,所以速度可能會比較慢,增加sort_buffer_size會減少sort_merge_passes和創建臨時文件的次數,但是盲目地增大sort_buffer_size並不一定能提高速度。   9、文件打開數(open_files) 我們在處理MySQL故障時,發現當open_files大於open_files_limit值時,MySQL數據庫就會發生卡住的現象,導致Apache服務器打不開相應的頁面,這個問題大家在工作中注意,我們可以利用如下命令查看其具體情況: mysql> show global status like 'open_files'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Open_files    | 25    | +---------------+-------+ 1 row in set (0.00 sec)   mysql> show variables like 'open_files_limit'; +------------------+-------+ | Variable_name    | Value | +------------------+-------+ | open_files_limit | 8192  | +------------------+-------+ 1 row in set (0.00 sec) 比較合適的配置:Open_files / open_files_limit * 100% <= 75%。 很多時候我們會發現,通過參數設置進行性能優化所帶來的性能提升,並不如許多人的想象的那樣會產生質的飛躍,除非是之前的設置存在嚴重不合理的情況。我們不能將性能調優完全依托於通過DBA在數據庫上線后進行參數調整,而應該在系統設計和開發階段就盡可能減少性能問題。   10、Innodb_buffer_pool_size的合理設置 InnoDB存儲引擎的緩存機制和MyISAM的最大區別就在於,InnoDB不僅僅緩存索引,同時還會緩存實際的數據。此參數用來設置InnoDB最主要的buffer(InnoDB buffer pool)的大小,也就是緩存用戶表及索引數據的最主要緩存空間,對InnoDB整體性能影響也最大。 無論是MySQL官方手冊還是網絡上許多人分享的InnoDB優化建議,都是簡單地建議將此值設置為整個系統物理內存的50%~80%。這么做法其實不妥,我們應要根據實際的運行場景來正確設置此項參數。以我的生產數據庫(表的引擎有InnoDB和MyISAM兩種)為例,物理服務器總內存為8GB,配置Innodb_buffer_pool_size=2048MB,網站穩定上線后,通過以下命令觀察: mysql> show status like 'Innodb_buffer_pool_%'; +-----------------------------------+------------+ | Variable_name                     | Value      | +-----------------------------------+------------+ | Innodb_buffer_pool_pages_data     | 63285      | | Innodb_buffer_pool_pages_dirty    | 3          | | Innodb_buffer_pool_pages_flushed  | 37081      | | Innodb_buffer_pool_pages_free     | 0          | | Innodb_buffer_pool_pages_misc     | 2251       | | Innodb_buffer_pool_pages_total    | 65536      | | Innodb_buffer_pool_read_ahead_rnd | 19214      | | Innodb_buffer_pool_read_ahead_seq | 16193      | | Innodb_buffer_pool_read_requests  | 3274048071 | | Innodb_buffer_pool_reads          | 562959     | | Innodb_buffer_pool_wait_free      | 0          | | Innodb_buffer_pool_write_requests | 1159654    | +-----------------------------------+------------+ 12 rows in set (0.00 sec) 通過此命令得出的結果可以計算出InnoDB buffer pool的read命中率大約為: (3274048071 - 63285) / 3274048071 = 99.99% write命中率大約為: 63285 / 65536 * 100% = 96.56% 我們發現這個值設置得過小,后期考慮將其增加到3072MB左右,另外需要注意的是,32位系統因為系統方面的制約,此值只能設置為2.2GB~2.7GB,所以建議大家的數據庫系統為64位。     另外,等MySQL在線上穩定運行一段時間后,可以使用MySQL調優腳本tuning-primer.sh來檢查參數設置的否全理。 下載地址:http://launchpad.net/mysql-tuning-primer/trunk/1.5-r5/+download/tuning-primer.sh。 該腳本使用“SHOW STATUS LIKE...”和“SHOW VARIABLES LIKE...”命令獲得MySQL相關變量和運行狀態。然后根據推薦的調優參數對當前的MySQL數據庫進行測試。最后根據不同顏色的標識來提醒用戶需要注意的各個參數設置。該版本目前兼容MySQL3.23和更高的版本(包含5.1),但是尚不支持MySQL5.5版本。 當前版本會處理如下這些推薦的參數: Slow Query Log (慢查詢日志) Max Connections (最大連接數) Worker Threads (工作線程) Key Buffer (Key 緩沖) Query Cache (查詢緩存) Sort Buffer (排序緩存) Joins (連接) Temp Tables(臨時表) Table (Open &amp;Definition)Cache(表緩存) Table Locking(表鎖定) Tables Scans(read_buffer)(表掃描,讀緩沖) InnoDB Status(InnoDB 狀態)   整個mysql的簡單優化就這樣,這些參數設置只是作為參考,實際需要還要看自己的服務器。 還有sql查詢語句的優化應該放在重中之重。

 

本文出自 “linux學習” 博客,請務必保留此出處http://zhou123.blog.51cto.com/4355617/1155375


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com