mysql的监控方法大体分为两类:mysql
1.链接到mysql数据库内部,使用show status,show variables,flush status 来查看mysql的各类性能指标。算法
2. 直接使用mysqladmin查看其性能指标,例如:sql
UserParameter=mysql.uptime,mysqladmin -uroot status|cut -f2 -d":"|cut -f1 -d"T"shell
mysqladmin两个参数,status,extended-status数据库
shell > mysqladmin -uroot -ppassword variables status缓存
可获得如下信息(后面详解)安全
--------------------------------------------------------------------------------------------------------------------------服务器
Uptime: 4557887 #mysql运行的秒数并发
Threads: 1 #链接数async
Questions: 1684130 #The number of questions (queries) from clients since the server was started.
Slow queries: 0 #The number of queries that have taken more than long_query_time seconds
Opens: 221872 #The number of tables the server has opened.
Flush tables: 1 #The number of flush-*, refresh, and reload commands the server has executed.
Open tables: 64 #The number of tables that currently are open.
Queries per second avg: 0.369 #从上次运行开始计算,每秒钟平均查询次数
-----------------------------------------------------------------------------------------------------
Questions = Com_* + Qcache_hits
最完整的信息
shell > mysqladmin -uroot -ppassword variables extended-status
其余的信息
shell > /usr/libexec/mysqld --verbose --help (这个命令生成全部mysqld选项和可配置变量的列表 )
mysql>SHOW STATUS; (服务器状态变量,运行服务器的统计和状态指标)
mysql> SHOW VARIABLES;(服务器系统变量,实际上使用的变量的值)
或者
mysql>SHOW STATUS LIKE '%变量名% ' ;
对配置参数的说明:
配置参数的格式以下:(shell > mysqladmin -uroot -ppassword variables extended-status)
-----------------------------
+-----------------------------------------+------------------------------------------------------------+
| Variable_name | Value |
+-----------------------------------------+------------------------------------------------------------+
| auto_increment_increment | 1 |
| auto_increment_offset | 1 |
| automatic_sp_privileges | ON |
.........
注:value 值的单位是byte ,要获得M ,需除以2次1024
-----------------------------------
Uptime 4405546
MySQL服务器已经运行的秒数
-----------------------------------
auto_increment_increment 1
auto_increment_offset 1
两个变量值都只能为1到65,535之间的整数值。设置为非整数值,则会给出错误。
这两个变量影响AUTO_INCREMENT列。
auto_increment_increment控制列中的值的增量值(步进量)。
auto_increment_offset肯定AUTO_INCREMENT列值的初始值。
通常不去更改。更改方法:mysql> SET @auto_increment_offset=5;
-----------------------------------------------------------------------------------------------------
max_connections 100
table_cache 64
open_files_limit 1024
Open_tables 64
Opened_tables 187690
几个参数的关系:
table_cache * 2 + max_connections=max_open_files
max_connections
默认为100
mysql>show processlist;
mysql>show full processlist;
-----------------------
-------------------------
max_open_files 由 open_files_limit 参数决定。
mysql打开的最大文件数,受两个参数的影响:系统打开的最大文件数(ulimit -n)和 open_files_limit 。
加大max_open_files的值
-------------------------------------------------------------
在/etc/my.cnf加入open_files_limit=8192
在/etc/security/limits.conf添加
* soft nofile 8192
* hard nofile 8192
--------------------------------------------------------------------
最好用sysctl或者修改/etc/sysctl.conf文件,同时还要在配置文件中把open_files_limit这个参数增大,对于4G内存服务器,open_files_limit至少要增大到4096,非特殊状况,设置成8192就能够了。
table_cache
MySQL 5.0升级到5.1,table_cache 更名table_open_cache
设置表高速缓存的数目。
表缓存的说明:
当 Mysql 访问一个表时,若是该表在缓存中已经被打开,则能够直接访问缓存;若是尚未被缓存,可是在 Mysql 表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区;若是表缓存满了,则会按照必定的规则将当前未用的表释放,或者临时扩大表缓存来存放,使用表缓存 的好处是能够更快速地访问表中的内容。
每一个链接进来,都会至少打开一个表缓存。所以, table_cache 的大小应与 max_connections 的设置有关。例如,对于 200 个并行运行的链接,应该让表的缓存至少有 200 × N ,这里 N 是网站程序一次查询所用到的表的最大值。
每一个线程会独自持有一个数据文件的文件描述符,而索引文件的文件描述符是公用的。当table cache不够用的时候,MySQL会采用LRU算法踢掉最长时间没有使用的表。若是table_cache设置太小,MySQL就会反复打开、关闭 frm文件,形成必定的性能损失。若是table_cache设置过大,MySQL将会消耗不少CPU去作 table cache的算法运算。
而InnoDB的元数据管理是放在共享表空间里面作的,因此获取表的结构不须要去反复解析frm文件,这是比MyISAM强的地方。即便 table_cache设置太小,对于InnoDB的影响也是很小的,由于它根本不须要反复打开、关闭frm文件去获取元数据。
合理设置table_cache的大小:经过查看open_tables,Opened_tables,Flush tables 的值来比较。
察看当前的表缓存状况:
shell > mysqladmin -uroot -ppassword variables status
----------------------------------
Opens: 221872 则是已经打开的表的数量。
Flush tables: 1
Open tables: 64 是当前打开的表的数量
----------------------------------
mysql> show global status like 'open%_tables';
----------------------------------
open_tables 是当前打开的表的数量,
Opened_tables 表示打开过的表数量
----------------------------------
清空表缓存
mysql> flush tables;
若是发现 open_tables 接近 table_cache 的时候,若是 Opened_tables 随着从新运行 SHOW STATUS 命令快速增长,就说明缓存命中率不够。而且屡次执行FLUSH TABLES(经过shell > mysqladmin -uroot -ppassword variables status ),那就说明可能 table_cache 设置的偏小,常常须要将缓存的表清出,将新的表放入缓存,这时能够考虑增长这个参数的大小来改善访问的效率。
若是 Open_tables 比 table_cache 设置小不少,就说明table_cache 设的太大了。
table_cache的值在2G内存如下的机器中的值默认时256到512,若是机器有4G内存,则默认这个值是2048,但这决意味着机器 内存越大,这个值应该越大,由于table_cache加大后,使得mysql对SQL响应的速度更快了,不可避免的会产生更多的死锁(dead lock),这样反而使得数据库整个一套操做慢了下来,严重影响性能。
注意,不能盲目地把table_cache设置成很大的值。若是设置得过高,可能会形成文件描述符不足,从而形成性能不稳定或者链接失败。
对于有1G内存的机器,推荐值是128-256。
--------------------------------------------------------------------
key_buffer_size 67108864(/1024/1024=64M)
Key_read_requests 40944 从缓存读键的数据块的请求数。
Key_reads 2711 从硬盘读取键的数据块的次数。
Key_write_requests 将键的数据块写入缓存的请求数。
Key_writes 向硬盘写入将键的数据块的物理写操做的次数。
(得到信息:
shell > mysqladmin -uroot -ppassword variables extended-status
shell>mysqladmin -uroot -ppassword variable status
mysql> show status like '%key_read%';
)
key_buffer_size设置索引块(index blocks)缓存的大小,保存了 MyISAM 表的索引块。它被全部线程共享,决定了数据库索引处理的速度,尤为是索引读的速度。理想状况下,对于这些块的请求应该来自于内存,而不是来自于磁盘。
只对MyISAM表起做用。即便你不使用MyISAM表,可是内部的临时磁盘表是MyISAM表,也要使用该值。
key_buffer_size: 若是不使用MyISAM存储引擎,16MB足以,用来缓存一些系统表信息等。若是使用 MyISAM存储引擎,在内存容许的状况下,尽量将全部索引放入内存,简单来讲就是“越大越好”
合理设置key_buffer_size的方法:
查看Key_read_requests和Key_reads的比例,
Key_reads 表明命中磁盘的请求个数, Key_read_requests 是总数。命中磁盘的读请求数除以读请求总数就是不中比率。若是每 1,000 个请求中命中磁盘的数目超过 1 个,就应该考虑增大关键字缓冲区了。
key_reads / key_read_requests的值应该尽量的低,好比1:100,1:1000 ,1:10000。
对于内存在4GB左右的服务器该参数可设置为256M或384M。
注意:该参数值设置的过大反而会是服务器总体效率下降!
--------------------------------------------------------------------------------------------------------
256MB内存和许多表,想要在中等数量的客户时得到最大性能,应使用:
shell> mysqld_safe --key_buffer_size=64M --table_cache=256 --sort_buffer_size=4M --read_buffer_size=1M &
-------------------------------------------------------------------------------------------------------------------------------------------------------
每一个链接到MySQL服务器的线程都须要有本身的缓冲,默认为其分配256K。事务开始以后,则须要增长更多的空间。运行较小的查询可能仅给指 定的线程增长少许的内存消耗,例如存储查询语句的空间等。但若是对数据表作复杂的操做比较复杂,例如排序则须要使用临时表,此时会分配大约 read_buffer_size,sort_buffer_size,read_rnd_buffer_size,tmp_table_size大小的 内存空间。不过它们只是在须要的时候才分配,而且在那些操做作完以后就释放了。
myisam_sort_buffer_size 8388608
当在REPAIR TABLE或用CREATE INDEX建立索引或ALTER TABLE过程当中排序 MyISAM索引分配之缓冲区。
sort_buffer_size 2097144
每一个排序线程分配的缓冲区的大小。增长该值能够加快ORDER BY或GROUP BY操做。
注意:该参数对应的分配内存是每一个链接独享,若是有100个链接,那么实际分配的总共排序缓冲区大小为100 × 6 = 600MB。因此,对于内存在4GB左右的服务器推荐设置为6-8M。
mysql> SHOW STATUS LIKE "sort%";
---------------------------
Sort_merge_passes 1
Sort_range 79192
Sort_rows 2066532
Sort_scan 44006
---------------------------
若是 sort_merge_passes 很大,就表示须要注意 sort_buffer_size。
当 MySQL 必需要进行排序时,就会在从磁盘上读取数据时分配一个排序缓冲区来存放这些数据行。若是要排序的数据太大,那么数据就必须保存到磁盘上的临时文件中,并再次进行排序。若是 sort_merge_passes 状态变量很大,这就指示了磁盘的活动状况。
read_buffer_size 131072
(show variables like 'read%';)
----------------
read_buffer_size 1048576
read_rnd_buffer_size 524288
---------------
read_buffer_size是MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySql会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。
每一个线程连续扫描时为扫描的每一个表分配的缓冲区的大小(字节)。若是进行屡次连续扫描,可能须要增长该值, 默认值为131072。和sort_buffer_size同样,该参数对应的分配内存也是每链接独享。
read_rnd_buffer_size
read_rnd_buffer_size是MySql的随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓 存区。进行排序查询时,MySql会首先扫描一遍该缓冲,以免磁盘搜索,提升查询速度,若是须要排序大量数据,可适当调高该值。该参数对应的分配内存也 是每链接独享。
join_buffer_size 131072
联合查询操做所能使用的缓冲区大小,和sort_buffer_size同样,该参数对应的分配内存也是每一个链接独享。
--------------------------------------------------------------------------------------------------------
max_allowed_packet 1048576
net_buffer_length 16384
包消息缓冲区初始化为net_buffer_length字节,但须要时能够增加到max_allowed_packet字节。该值默认很小,以捕获大的(多是错误的)数据包。
--------------------------------------------------------------------------------------------------------
thread_stack 196608
每一个线程的堆栈大小。用crash-me测试检测出的许多限制取决于该值。 默认值足够大,能够知足普通操做。
--------------------------------------------------------------------------------------------------------
thread_cache_size 0
query_cache_size 0
tmp_table_size 33554432
innodb_thread_concurrency 8
max_connections 100
max_connect_errors 10
(得到信息:
shell > mysqladmin -uroot -ppassword variables extended-status
shell>mysqladmin -uroot -ppassword variable status
)
thread_cache_size
(
mysql> show status LIKE 'threads%';
)
---------------------------
Threads_cached 27
Threads_connected 15
Threads_created 838610
Threads_running 3
----------------------------
线程缓存。mysqld 在接收链接时会根据须要生成线程。在一个链接变化很快的繁忙服务器上,对线程进行缓存便于之后使用能够加快最初的链接。
此处重要的值是 Threads_created,每次 mysqld 须要建立一个新线程时,这个值都会增长。若是这个数字在连续执行 SHOW STATUS 命令时快速增长,就应该尝试增大线程缓存。
query_cache_size
mysql> SHOW VARIABLES LIKE 'have_query_cache';
mysql> show variables like '%query%';
------------------------------------
ft_query_expansion_limit 20
have_query_cache YES
long_query_time 10.000000
query_alloc_block_size 8192
query_cache_limit 1048576
query_cache_min_res_unit 4096
query_cache_size 0
query_cache_type ON
query_cache_wlock_invalidate OFF
query_prealloc_size 8192
slow_query_log OFF
slow_query_log_file /var/run/mysqld/mysqld-slow.log
-------------------------------------
have_query_cache 是否有查询缓存
query_cache_limit 指定单个查询可以使用的缓冲区大小,缺省为1M
query_cache_type 变量影响其工做方式。这个变量能够设置为下面的值:
0 或OFF 将阻止缓存或查询缓存结果。
1 或ON 将容许缓存,以SELECT SQL_NO_CACHE 开始的查询语句除外。
2 或DEMAND , 仅对以SELECT SQL_CACHE 开始的那些查询语句启用缓存。
若是所有使用innodb存储引擎,建议为0,若是使用MyISAM 存储引擎,建议为2
query_cache_min_res_unit 是在4.1版本之后引入的,它指定分配缓冲区空间的最小单位,缺省为4K。检查状态值Qcache_free_blocks,若是该值很是大,则代表缓 冲区中碎片不少,这就代表查询结果都比较小,此时须要减少 query_cache_min_res_unit。
query_cache_size 为了存储老的查询结果而分配的内存数量 (以字节指定) 。若是设置它为 0 ,查询缓冲将被禁止(缺省值为 0 )。 根据 命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))进行调整,通常不建议太大,256MB可能已经 差很少了,大型的配置型静态数据可适当调大
mysql> SHOW STATUS LIKE 'qcache%';
---------------------------------------
Qcache_free_blocks 5216
Qcache_free_memory 14640664
Qcache_hits 2581646882
Qcache_inserts 360210964
Qcache_lowmem_prunes 281680433
Qcache_not_cached 79740667
Qcache_queries_in_cache 16927
Qcache_total_blocks 47042
-----------------------------------------
Qcache_free_blocks 缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理,从而获得一个空闲块。
Qcache_free_memory 缓存中的空闲内存。
Qcache_hits 每次查询在缓存中命中时就增大。
Qcache_inserts 每次插入一个查询时就增大。 未命中而后插入。
Qcache_lowmem_prunes 的值很是大,则代表常常出现缓冲不够的状况,同时Qcache_hits的值很是大,则代表查询缓冲使用很是频繁,此时须要增长缓冲大 小,Qcache_hits的值不大,则代表你的查询重复率很低,这种状况下使用查询缓冲反而会影响效率,那么能够考虑不用查询缓冲。这个数字最好长时间 来看;若是这个数字在不断增加,就表示可能碎片很是严重,或者内存不多。(上面的 free_blocks 和 free_memory 能够告诉您属于哪一种状况)。
Qcache_not_cached 不适合进行缓存的查询的数量,一般是因为这些查询不是 SELECT 语句。
Qcache_queries_in_cache 当前缓存的查询(和响应)的数量。
Qcache_total_blocks 缓存中块的数量。
Total number of queries = Qcache_inserts + Qcache_hits + Qcache_not_cached.
查询命中率=Qcache_hits -Qcache_inserts /Qcache_hits
查询插入率=Qcache_inserts / Com_select;
未插入率 = Qcache_not_cached / Com_select;
不少 LAMP 应用程序都严重依赖于数据库,但却会反复执行相同的查询。每次执行查询时,数据库都必需要执行相同的工做 —— 对查询进行分析,肯定如何执行查询,从磁盘中加载信息,而后将结果返回给客户机。MySQL 有一个特性称为查询缓存,查询缓存会存储一个 SELECT 查询的文本与被传送到客户端的相应结果。若是以后接收到一个一样的查询,服务器将从查询缓存中检索结果,而不是再次分析和执行这个一样的查询。在不少状况 下,这会极大地提升性能。不过,问题是查询缓存在默认状况下是禁用的。
一般,间隔几秒显示这些变量就能够看出区别,这能够帮助肯定缓存是否正在有效地使用。运行 FLUSH STATUS 能够重置一些计数器,若是服务器已经运行了一段时间,这会很是有帮助。
使用很是大的查询缓存,指望能够缓存全部东西,这种想法很是诱人。但若是表有变更时,首先要把Query_cache和该表相关的语句所有置为失效,而后在写入更新。
那么若是Query_cache很是大,该表的查询结构又比较多,查询语句失效也慢,一个更新或是Insert就会很慢,这样看到的就是Update或是Insert怎么这么慢了。
因此在数据库写入量或是更新量也比较大的系统,该参数不适合分配过大。并且在高并发,写入量大的系统,建系把该功能禁掉。
做为一条规则,若是 FLUSH QUERY CACHE 占用了很长时间,那就说明缓存太大了。
--------------------------------------------------------------------------------------------------------
wait_timeout 28800
服务器关闭非交互链接以前等待活动的秒数。
在线程启动时,根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值,取决于客户端类型
connect_timeout 10
mysqld服务器用Bad handshake响应前等待链接包的秒数。
interactive_timeout 28800
服务器关闭交互式链接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。
--------------------------------------------------------------------------------------------------------
mysql> SHOW STATUS LIKE "com_select";
-------------------------------
Com_select 318243
-------------------------------
mysql> SHOW STATUS LIKE "handler_read_rnd_next";
-------------------------------
Handler_read_rnd_next 165959471
-----------------------------------
MySQL 也会分配一些内存来读取表。理想状况下,索引提供了足够多的信息,能够只读入所须要的行,可是有时候查询(设计不佳或数据本性使然)须要读取表中大量数 据。要理解这种行为,须要知道运行了多少个 SELECT 语句,以及须要读取表中的下一行数据的次数(而不是经过索引直接访问)。
Handler_read_rnd_next / Com_select 得出了表扫描比率 —— 在本例中是 521:1。若是该值超过 4000,就应该查看 read_buffer_size,例如 read_buffer_size = 4M。若是这个数字超过了 8M,就应该与开发人员讨论一下对这些查询进行调优了!
--------------------------------------------------------------------------------------------------------
mysql> SHOW STATUS LIKE 'created_tmp%';
------------------------
Created_tmp_disk_tables 30660
Created_tmp_files 2
Created_tmp_tables 32912
---------------------
临时表能够在更高级的查询中使用,其中数据在进一步进行处理(例如 GROUP BY 字句)以前,都必须先保存到临时表中;理想状况下,在内存中建立临时表。可是若是临时表变得太大,就须要写入磁盘中。
每次使用临时表都会增大 Created_tmp_tables;基于磁盘的表也会增大 Created_tmp_disk_tables。对于这个比率,并无什么严格的规则,由于这依赖于所涉及的查询。长时间观察 Created_tmp_disk_tables 会显示所建立的磁盘表的比率,您能够肯定设置的效率。 tmp_table_size 和 max_heap_table_size 均可以控制临时表的最大大小,所以请确保在 my.cnf 中对这两个值都进行了设置。
-------------------------------------------------------------------------------------------------------
日志相关
log-bin=mysql-bin
binlog_format=mixed
mysql-bin.00000一、mysql-bin.000002等文件是数据库的操做日志,例如UPDATE一个表,或者DELETE一些数据,即便该语句没有匹配的数据,这个命令也会存储到日志文件中,还包括每一个语句执行的时间,也会记录进去的。
=================================================================================================
InnoDB
innodb_buffer_pool_size
innodb_buffer_pool_size 定义了 InnoDB 存储引擎的表数据和索引数据的最大内存缓冲区大小。和 MyISAM 存储引擎不一样, MyISAM 的 key_buffer_size 只能缓存索引键,而 innodb_buffer_pool_size 却能够缓存数据块和索引键。适当的增长这个参数的大小,能够有效的减小 InnoDB 类型的表的磁盘 I/O 。为Innodb加速优化首要参数。默认值8M
这个参数不能动态更改,因此分配需多考虑。分配过大,会使Swap占用过多,导致Mysql的查询特慢。若是你的数据量不大,而且不会暴增,那 么可分配是你的数据大小+10%左右作为这个参数的值。例如:数据大小为50M,那么给这个值分配 innodb_buffer_pool_size=64M
mysql>show variables like 'innodb%';
---------------------
innodb_adaptive_hash_index ON
innodb_additional_mem_pool_size 2097152
innodb_autoextend_increment 8
innodb_autoinc_lock_mode 1
innodb_buffer_pool_size 67108864
innodb_checksums ON
innodb_commit_concurrency 0
innodb_concurrency_tickets 500
innodb_data_file_path ibdata1:10M:autoextend
innodb_data_home_dir /var/lib/mysql
innodb_doublewrite ON
innodb_fast_shutdown 1
innodb_file_io_threads 4
innodb_file_per_table OFF
innodb_flush_log_at_trx_commit 1
innodb_flush_method
innodb_force_recovery 0
innodb_lock_wait_timeout 50
innodb_locks_unsafe_for_binlog OFF
innodb_log_buffer_size 8388608
innodb_log_file_size 16777216
innodb_log_files_in_group 2
innodb_log_group_home_dir /var/lib/mysql
innodb_max_dirty_pages_pct 90
innodb_max_purge_lag 0
innodb_mirrored_log_groups 1
innodb_open_files 300
innodb_rollback_on_timeout OFF
innodb_stats_method nulls_equal
innodb_stats_on_metadata ON
innodb_support_xa ON
innodb_sync_spin_loops 20
innodb_table_locks ON
innodb_thread_concurrency 8
innodb_thread_sleep_delay 10000
innodb_use_legacy_cardinality_algorithm ON
----------------------
mysql>show status like 'innodb%';
----------------
Innodb_buffer_pool_pages_data 2559 分配出去, 正在被使用页的数量,包括脏页。单位是page
Innodb_buffer_pool_pages_dirty 0 脏页但没有被flush除去的页面数。单位是page
Innodb_buffer_pool_pages_flushed 795 已经flush的页面数。单位是page
Innodb_buffer_pool_pages_free 1473 当前空闲页面数。单位是page
Innodb_buffer_pool_pages_misc 64 缓存池中当前已经被用做管理用途或hash index而不能用做为普通数据页的数目。单位是page
Innodb_buffer_pool_pages_total 4096 缓冲区总共的页面数。单位是page
Innodb_buffer_pool_read_ahead_rnd 8 随机预读的次数
Innodb_buffer_pool_read_ahead_seq 1 顺序预读的次数
Innodb_buffer_pool_read_requests 1725871 从缓冲池中读取页的次数
Innodb_buffer_pool_reads 2108 从磁盘读取页的次数。缓冲池里面没有, 就会从磁盘读取
Innodb_buffer_pool_wait_free 0 缓冲池等待空闲页的次数,当须要空闲块而系统中没有时,就会等待空闲页面
Innodb_buffer_pool_write_requests 2296 缓冲池总共发出的写请求次数
Innodb_data_fsyncs 695 总共完成的fsync次数
Innodb_data_pending_fsyncs 0 innodb当前等待的fsync次数
Innodb_data_pending_reads 0 innodb当前等待的读的次数
Innodb_data_pending_writes 0 innodb当前等待的写的次数
Innodb_data_read 44044288 总共读入的字节数
Innodb_data_reads 2191 innodb完成的读的次数
Innodb_data_writes 1296 innodb完成的写的次数
Innodb_data_written 26440192 总共写出的字节数
Innodb_dblwr_pages_written 795
Innodb_dblwr_writes 90
Innodb_log_waits 0 因日志缓存过小而必须等待其被写入所形成的等待数。单位是次。
Innodb_log_write_requests 263
Innodb_log_writes 410
Innodb_os_log_fsyncs 500
Innodb_os_log_pending_fsyncs 0
Innodb_os_log_pending_writes 0
Innodb_os_log_written 343552
Innodb_page_size 16384
Innodb_pages_created 4
Innodb_pages_read 2555
Innodb_pages_written 795
Innodb_row_lock_current_waits 0
Innodb_row_lock_time 0
Innodb_row_lock_time_avg 0
Innodb_row_lock_time_max 0
Innodb_row_lock_waits 0
Innodb_rows_deleted 0
Innodb_rows_inserted 352
Innodb_rows_read 818617
Innodb_rows_updated 88
------------------
命中率=innodb_buffer_pool_read_requests / (innodb_buffer_pool_read_requests + innodb_buffer_pool_read_ahead + innodb_buffer_pool_reads)
innodb_buffer_pool_size: 若是不使用InnoDB存储引擎,能够不用调整这个参数,若是须要使用,在内存容许的状况下,尽量将全部的InnoDB数据文件存放如内存中,一样将但来讲也是“越大越好”
innodb_additional_pool_size
这个值不用分配太大,系统能够自动调。不用设置过高。一般比较大数据设置16M够用了,若是表比较多,能够适当的增大。若是这个值自动增长,会在error log有中显示的。20M足够了。
innodb_log_file_size
做用:指定日志的大小
分配原则:几个日志成员大小加起来差很少和你的innodb_buffer_pool_size相等。在高写入负载尤为是大数据集的状况下很重要。这个值越大则性能相对越高,可是要注意到可能会增长恢复时间。
说明:这个值分配的大小和数据库的写入速度,事务大小,异常重启后的恢复有很大的关系。
innodb_log_buffer_size:
做用:事务在内存中的缓冲。
分配原则:控制在2-8M.这个值不用太多的。他里面的内存通常一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。通常最大指定为3M比较合适。
参考:Innodb_os_log_written(show global status 能够拿到)
若是这个值增加过快,能够适当的增长innodb_log_buffer_size
另外若是你须要处理大理的text,或是blog字段,能够考虑增长这个参数的值。
默认的设置在中等强度写入负载以及较短事务的状况下,服务器性能还能够。若是存在更新操做峰值或者负载较大,就应该考虑加大它的值了。若是它 的值设置过高了,可能会浪费内存 -- 它每秒都会刷新一次,所以无需设置超过1秒所需的内存空间。一般 8-16MB 就足够了。越小的系统它的值越小。
innodb_flush_logs_at_trx_commit
做用:控制事务的提交方式
分配原则:这个参数只有3个值,0,1,2请确认一下自已能接受的级别。默认为1,主库请不要更改了。性能更高的能够设置为0或是2,但会丢失一秒钟的事务。
值为1时:innodb 的事务LOG在每次提交后写入日志文件,并对日志作刷新到磁盘。这个能够作到不丢任何一个事务。
值为2事,也就是不把日志刷新到磁盘上,而只刷新到操做系统的缓存上。日志仍然会每秒刷新到磁盘中去,所以一般不会丢失每秒1-2次更新的消 耗。若是设置为 0 就快不少了,不过也相对不安全了 -- MySQL服务器崩溃时就会丢失一些事务。设置为 2 只会丢失刷新到操做系统缓存的那部分事务。
innodb_file_per_table
做用:使每一个Innodb的表,有自已独立的表空间。如删除文件后能够回收那部分空间。
分配原则:只有使用不使用。但DB还须要有一个公共的表空间。
InnoDB 默认会将全部的数据库InnoDB引擎的表数据存储在一个共享空间中:ibdata1,增删数据库的时候,ibdata1文件不会自动收缩,单个数据库的备份也将成为问题。一般只能将数据使用mysqldump 导出,而后再导入解决这个问题。
查看是否开启:
mysql> show variables like ‘%per_table%’;
开启
innodb_file_per_table=1
请适当的增长innodb_open_files
innodb_open_files
做用:限制Innodb能打开的表的数据。
分配原则:若是库里的表特别多的状况,请增长这个。这个值默认是300。这个值必须超过你配置的innodb_data_file_path个数。
请适当的增长table_cache
innodb_flush_method
做用:Innodb和系统打交道的一个IO模型
分配原则:Windows不用设置。UNIX能够设置:fdatasync (默认设置),O_DIRECT,和O_DSYNC
O_DIRECT跳过了操做系统的文件系统Disk Cache,让MySQL直接读写磁盘。 有数据代表,若是是大量随机写入操做,O_DIRECT会提高效率。可是顺序写入和读取效率都会下降。
innodb_max_dirty_pages_pct
做用:控制Innodb的脏页在缓冲中在那个百分比之下,值在范围1-100,默认为90.
O_DIRECT的flush_method更适合于操做系统内存有限的状况下(能够避免没必要要的对交换空间的读写操做),不然,它会因为禁用了os的缓冲下降对数据的读写操做的效能。
使用memlock能够避免MySQL内存进入swap