序号 | 参数 | 默认值 | 物理内存 | 说明 | ||||
16G | 32G | 64G | 128G | 256G | ||||
[mysqld] | ||||||||
1 | thread_concurrency | 8 | 16 | #推荐设置为服务器 CPU核数的2倍。推荐设置为服务器 CPU核数的2倍,例如双核的CPU, 那么thread_concurrency的应该为4;2个双核的cpu, thread_concurrency的值应为8。默认为8 | ||||
2 | thread_stack | 64K | 512K | # 线程使用的堆大小. 此容量的内存在每次连接时被预留. # MySQL 本身常不会需要超过 64K 的内存 # 如果你使用你自己的需要大量堆的 UDF 函数或者你的操作系统对于某些操作需要更多的堆,你也许需要将其设置的更高一点. |
||||
3 | thread_cache_size | 110 | 80 | #线程缓存。可以复用的保存在中的线程的数量。如果有,新的线程从缓存中取得,当断开连接的时候如果有空间,客户的线置在缓存中。如果有很多新的线程,为了提高性能可以这个变量值。 | ||||
4 | transaction_isolation | REPEATABLE-READ | REPEATABLE-READ | # 设定默认的事务隔离级别.可用的级别如下: # READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE |
||||
5 | table_cache | 128 | 1024 | 高速缓存的大小。每当MySQL访问一个表时,如果在表缓冲区中还有空间,该表就被打开并放入其中,这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables,可以决定是否需要增加table_cache的值。如 果你发现open_tables等于table_cache,并且opened_tables在不断增长,那么你就需要增加table_cache的值了 (上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得)。注意,不能盲目地把table_cache设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能 不稳定或者连接失败。比较合适的值为: Open_tables / Opened_tables * 100% >= 85% Open_tables / table_cache * 100% <= 95% 1G内存机器,推荐值是128-256。内存在4GB左右的服务器该参数可设置为256M或384M。 |
||||
6 | table_open_cache | 1024 | 4096 | #同样是缓存表大小。MySQL 5.6相比于前代GA版本性能提升显著,但默认缓存设置对于小型站点并不合理。 open_tables等于table_open_cache,都是512,说明mysql正在将缓存的表释放以容纳新的表,此时可能需要加大table_open_cache的值,4G内存的机器,建议设置为2048 比较适合的值: Open_tables / Opened_tables >= 0.85 Open_tables / table_open_cache <= 0.95 |
||||
7 | table_definition_cache | 1400 | 400 | 存放表的定义信息。是frm文件在内存中的映射。MySQL需要打开frm文件,并将其内容初始化为Table Share 对象。这里存放与存储引擎无关的,独立的表定义相关信息。 为什么MySQL会出现这两个概念是因为:MySQL支持不同的存储引擎,每种存储引擎,数据存储的格式都是不一样的,因此需要指定一个存储引擎相关的handler。这就有了table cache的作用。另外表的定义也需要存放内存中,而表的定义frm文件每个存储引擎是通用的,需要另外独立开来,这就有了table definition cache。 |
||||
8 | table_cache_instances | 1 | 16 | MySQL 5.6后,引入了“table_cache_instances”参数来控制 table cache instance的个数。目前最大值是64,默认值是1。建议值是16,当系统CPU核数高于16时。引入此参数的目的是,提高并发。相当于把table cache 拆成了多个分区,每个分区的打开table句柄数为:table_open_cache / table_open_cache_instances。 | ||||
9 | tmp_table_size | 16M | 256M | 512M | 512M | 512M | 512M | #cache #内部内存临时表的最大值。 通过设置tmp_table_size选项来增加一张临时表的大小,例如做高级GROUP BY操作生成的临时表。如果调高该值,MySQL同时将增加heap表的大小,可达到提高联接查询速度的效果,建议尽量优化查询,要确保查询过程中生成的临时表在内存中,避免临时表过大导致生成基于硬盘的MyISAM表。 默认为16M,可调到64-256最佳,线程独占,太大可能内存不够I/O堵塞 |
10 | slow_query_log | ON | ||||||
11 | slow_launch_time | 2 | 5 | 5 | 5 | 5 | 5 | 超过5秒的查询语句为慢SQL |
12 | slow_query_log_file | mysql-slow.log | 慢SQL日志所在位置 /var/lib/mysql/mysql-slow.log |
|||||
13 | max_connections | 3000 | 2000 | #连接数。MySQL的最大连接数,增加该值增加mysqld 要求的文件描述符的数量。如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多, 介于MySQL会为每个连接提供连接缓冲区,就会开销越多的内存,所以要适当调整该值,不能盲目提高设值。 | ||||
14 | max_connect_errors | 6000 | 1000 | #是一个MySQL中与安全有关的计数器值,它负责阻止过多尝试失败的客户端以防止暴力破解密码 | ||||
15 | back_log | 50 | 128 | 128 | 256 | 256 | 512 | #MySQL能暂存的连接数量(根据实际设置) MySQL能暂存的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求,这就起作用。如果MySQL的连接数据达到 max_connections时,新来的请求将会被存在堆栈中,以等待某一连接释放资源,该堆栈的数量即back_log,如果等待连接的数量超过 back_log,将不被授予连接资源。 back_log值指出在MySQL暂时停止回答新请求之前的短时间内有多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接,你需要增加它,换句话说,这值对到来的TCP/IP连接的侦听队列的大小。 当观察你主机进程列表(mysql> show full processlist),发现大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时,就要加大back_log 的值了。 默认数值是50,可调优为128,对系统设置范围为小于512的整数。 |
16 | Innodb_File_Per_Table | 0 | 1 | 每一个表都将会生成以独立的文件方式来进行存储,每一个表都有一个.frm表描述文件,还有一个.ibd文件。 其中这个文件包括了单独一个表的数据内容以及索引内容,默认情况下它的存储位置也是在表的位置之中。 | ||||
17 | innodb_buffer_pool_size | 256M | 8G | 16G | 32G | 64G | 128G | 对于InnoDB表来说,innodb_buffer_pool_size的作用就相当于key_buffer_size对于MyISAM表的作用一样。InnoDB使用该参数指定大小的内存来缓冲数据和索引。对于单独的MySQL数据库服务器,最大可以把该值设置成物理内存的80%。 根据MySQL手册,对于2G内存的机器,推荐值是1G(50%)。 |
18 | innodb_flush_log_at_trx_commit | 1 | 0 | 主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点,取值分别为0、1、2三个。0,表示当事务提交时,不做日志写入操作,而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次;1,则在每秒钟或是每次事物的提交都会引起日志文件写入、flush磁盘的操作,确保了事务的 ACID;设置为2,每次事务提交引起写入日志文件的动作,但每秒钟完成一次flush磁盘操作。 实际测试发现,该值对插入数据的速度影响非常大,设置为2时插入10000条记录只需要2秒,设置为0时只需要1秒,而设置为1时则需要229秒。因此,MySQL手册也建议尽量将插入操作合并成一个事务,这样可以大幅提高速度。 根据MySQL手册,在允许丢失最近部分事务的危险的前提下,可以把该值设为0或2。 |
||||
19 | innodb_log_buffer_size | 2M | 16M | 32M | 32M | 64M | 64M | log缓存大小,一般为1-8M,默认为1M,对于较大的事务,可以增大缓存大小。 可设置为4M或8M。 |
20 | innodb_log_file_size | 8M | 512M | # 在日志组中每个日志文件的大小. # 你应该设置日志文件总合大小到你缓冲池大小的25%~100% # 来避免在日志文件覆写上不必要的缓冲池刷新行为. # 不论如何, 请注意一个大的日志文件大小会增加恢复进程所需要的时间 |
||||
21 | innodb_additional_mem_pool_size | 1M | 64M | 128M | 128M | 256M | 512M | 该参数指定InnoDB用来存储数据字典和其他内部数据结构的内存池大小。缺省值是1M。通常不用太大,只要够用就行,应该与表结构的复杂度有关系。如果不够用,MySQL会在错误日志中写入一条警告信息。 根据MySQL手册,对于2G内存的机器,推荐值是20M,可适当增加。 |
22 | innodb_thread_concurrency | 8 | 8 | 16 | 32 | 64 | 64 | 推荐设置为 2*(NumCPUs+NumDisks),默认一般为8 |
23 | innodb_write_io_threads | 16 | 16 | 32 | 32 | 32 | 32 | 脏页写的线程数,加大该参数可以提升写入性能.mysql5.5以上才有 |
24 | innodb_flush_log_at_trx_commit | 0 | 2 | 设置0是事务log(ib_logfile0、ib_logfile1)每秒写入到log buffer,1是时时写,2是先写文件系统的缓存,每秒再刷进磁盘,和0的区别是选2即使mysql崩溃也不会丢数据。 | ||||
25 | innodb_max_dirty_pages_pct | 75 | 75 | 当系统中 脏页 所占百分比超过这个值,INNODB就会进行写操作以把页中的已更新数据写入到磁盘文件中。默认75,一般现在流行的SSD硬盘很难达到这个比例。可依据实际情况在75-80之间调节 | ||||
26 | innodb_io_capacity | 5000 | 5000 | 从缓冲区刷新脏页时,一次刷新脏页的数量。根据磁盘IOPS的能力一般建议设置如下: SAS 200 SSD 5000 PCI-E 10000-50000 |
||||
27 | innodb_flush_method | fdatasync | O_DIRECT | 控制innodb数据文件和redo log的打开、刷写模式。有三个值:fdatasync(默认),O_DSYNC,O_DIRECT。 • fdatasync模式:写数据时,write这一步并不需要真正写到磁盘才算完成(可能写入到操作系统buffer中就会返回完成),真正完成是flush操作,buffer交给操作系统去flush,并且文件的元数据信息也都需要更新到磁盘。 • O_DSYNC模式:写日志操作是在write这步完成,而数据文件的写入是在flush这步通过fsync完成。 • O_DIRECT模式:数据文件的写入操作是直接从mysql innodb buffer到磁盘的,并不用通过操作系统的缓冲,而真正的完成也是在flush这步,日志还是要经过OS缓冲。 |
||||
28 | innodb_adaptive_flushing | off | ON | 影响每秒刷新脏页的数目。规则由原来的“大于innodb_max_dirty_pages_pct时刷新100个脏页到磁盘”变为 “通过buf_flush_get_desired_flush_reate函数判断重做日志产生速度确定需要刷新脏页的最合适数目”;即使脏页比例小于 innodb_max_dirty_pages_pct时也会刷新一定量的脏页。 | ||||
29 | innodb_max_dirty_pages_pct | 20 | 90 | # 在 InnoDB 缓冲池中最大允许的脏页面的比例. # 如果达到限额, InnoDB 会开始刷新他们防止他们妨碍到干净数据页面. # 这是一个软限制,不被保证绝对执行 |
||||
30 | innodb_stats_on_metadata | OFF | OFF | 关掉一些访问information_schema库下表而产生的索引统计。 当重启mysql实例后,mysql会随机的io取数据遍历所有的表来取样来统计数据,这个实际使用中用的不多,建议关闭. |
||||
31 | innodb_change_buffering | all | all | 当更新/插入的非聚集索引的数据所对应的页不在内存中时(对非聚集索引的更新操作通常会带来随机IO),会将其放到一个insert buffer中,当随后页面被读到内存中时,会将这些变化的记录merge到页中。当服务器比较空闲时,后台线程也会做merge操作。 由于主要用到merge的优势来降低io,但对于一些场景并不会对固定的数据进行多次修改,此处则并不需要把更新/插入操作开启change_buffering,如果开启只是多余占用了buffer_pool的空间和处理能力。这个参数要依据实际业务环境来配置。 |
||||
32 | innodb_old_blocks_time | 0 | 1000 | 使Block在old sublist中停留时间长为1s,不会被转移到new sublist中,避免了Buffer Pool被污染BP可以被认为是一条长链表。被分成young 和 old两个部分,其中old默认占37%的大小(由innodb_old_blocks_pct 配置)。靠近顶端的Page表示最近被访问。靠近尾端的Page表示长时间未被访问。而这两个部分的交汇处成为midpoint。每当有新的Page需要加载到BP时,该page都会被插入到midpoint的位置,并声明为old-page。当old部分的page,被访问到时,该page会被提升到链表的顶端,标识为young。 由于table scan的操作是先load page,然后立即触发一次访问。所以当innodb_old_blocks_time =0 时,会导致table scan所需要的page不读的作为young page被添加到链表顶端。而一些使用较为不频繁的page就会被挤出BP,使得之后的SQL会产生磁盘IO,从而导致响应速度变慢。 这时虽然mysqldump访问的page会不断加载在LRU顶端,但是高频度的热点数据访问会以更快的速度把page再次抢占到LRU顶端。从而导致mysqldump加载入的page会被迅速刷下,并立即被evict(淘汰)。因此,time=0或1000对这种压力环境下的访问不会造成很大影响,因为dump的数据根本抢占不过热点数据。不只dump,当大数据操作的时候也是如此。 |
||||
33 | innodb_lock_wait_timeout | 3600 | 120 | # 在被回滚前,一个 InnoDB 的事务应该等待一个锁被批准多久. # InnoDB 在其拥有的锁表中自动检测事务死锁并且回滚事务. # 如果你使用 LOCK TABLES 指令, 或者在同样事务中使用除了 InnoDB 以外的其他事务安全的存储引擎 # 那么一个死锁可能发生而 InnoDB 无法注意到. # 这种情况下这个 timeout 值对于解决这种问题就非常有帮助. |
||||
34 | wait_timeout | 120 | 10 | 指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。 | ||||
35 | interactive_timeout | 28800 | 7200 | 一个交互连接在被服务器在关闭前等待行动的秒数。一个交互的客户被定义为对mysql_real_connect()使用CLIENT_INTERACTIVE 选项的客户。 默认数值是28800,可调优为7200。 |
||||
36 | binlog_cache_size | 32K | 8M | 为每个session 分配的内存,在事务过程中用来存储二进制日志的缓存。 show global status like 'bin%';上述语句我们可以得到当前 数据库binlog_cache_size的使用情况 Binlog_cache_disk_use表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数 Binlog_cache_use 表示 用binlog_cache_size缓存的次数 当对应的Binlog_cache_disk_use 值比较大的时候 我们可以考虑适当的调高 binlog_cache_size 对应的值 a.max_binlog_cache_size 表示的是binlog 能够使用的最大cache 内存大小 当我们执行多语句事务的时候 所有session的使用的内存超过max_binlog_cache_size的值时 就会报错:“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage” b.设置太大的话,会比较消耗内存资源;设置太小又会使用到临时文件即disk |
||||
37 | performance_schema_max_table_instances | 12500 | 600 | 通过修改my.cnf文件中的performance_schema_max_table_instances参数,能够有效降低内存占用。 | ||||
38 | max_heap_table_size | 1M | 128M | 256M | 512M | 512M | 512M | # 独立的内存表所允许的最大容量. # 此选项为了防止意外创建一个超大的内存表导致永尽所有的内存资源. #内部内存临时表的最大值,每个线程都要分配 用户可以创建的内存表(memory table)的大小。这个值用来计算内存表的最大行数值。这个变量支持动态改变,即set @max_heap_table_size=# 这个变量和tmp_table_size一起限制了内部内存表的大小。如果某个内部heap(堆积)表大小超过tmp_table_size,MySQL可以根据需要自动将内存中的heap表改为基于硬盘的MyISAM表。 |
39 | key_buffer_size | 8M | 1G | 2G | 4G | 8G | 16G | #指定索引缓冲区的大小,只对MyISAM表起作用,这里写上也没有关系。key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。 key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表,但是内部的临时磁盘表是MyISAM表,也要使用该值。主机内存的1/16.4G内存配置256M |
40 | sort_buffer_size | 256K | 32M | 64M | 128M | 256M | 512M | # Sort_Buffer_Size 是一个connection级参数,在每个connection(session)第一次需要使用这个buffer的时候,一次性分配设置的内存。 #Sort_Buffer_Size 并不是越大越好,由于是connection级的参数,过大的设置+高并发可能会耗尽系统内存资源。例如:500个连接将会消耗 500*sort_buffer_size(8M)=4G内存 #Sort_Buffer_Size 超过2KB的时候,就会使用mmap() 而不是 malloc() 来进行内存分配,导致效率降低。 |
41 | record_buffer_size | 128K | 32M | 64M | 128M | 256M | 512M | 每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,你可能想要增加该值。 默认数值是131072(128K),可改为16773120 (16M) |
42 | read_buffer_size | 8M | 64M | 64M | 128M | 256M | 512M | #当一个查询不断地扫描某一个表,MySQL会为它分配一段内存缓冲区 |
43 | read_rnd_buffer_size | 16M | 32M | 64M | 128M | 256M | 512M | #随机读取数据缓冲区使用内存。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySQL会首先扫描一遍该缓冲,以避 免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开 销过大。 一般可设置为16M |
44 | join_buffer_size | 16M | 1024M | 1024M | 2048M | 2048M | 2048M | #表和表联接的缓冲区的大小。联合查询操作所能使用的缓冲区大小 record_buffer_size,read_rnd_buffer_size,sort_buffer_size,join_buffer_size为每个线程独占,也就是说,如果有100个线程连接,则占用为16M*100 |
45 | myisam_sort_buffer_size | 1M | 256M | # 此缓冲当 MySQL 需要在 REPAIR, OPTIMIZE, ALTER 以及 LOAD DATA INFILE 到一个空表中引起重建索引时被分配. # 这在每个线程中被分配.所以在设置大值时需要小心. |
||||
46 | myisam_max_sort_file_size | 256M | 10G | # MySQL 重建索引时所允许的最大临时文件的大小 (当 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE). # 如果文件大小比此值更大,索引会通过键值缓冲创建(更慢) |
||||
47 | query_cache_type | 0 | 1 | #将查询结果放入查询缓存中 | ||||
48 | query_cache_size | 128M | 256M | 512M | 1024M | 2048M | 4096M | #查询缓存大小。使用查询缓冲,MySQL将查询结果存放在缓冲区中,今后对于同样的SELECT语句(区分大小写),将直接从缓冲区中读取结果。 通过检查状态值Qcache_*,可以知道query_cache_size设置是否合理(上述状态值可以使用SHOW STATUS LIKE ‘Qcache%’获得)。如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况,如果Qcache_hits的值也 非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小;如果Qcache_hits的值不大,则表明你的查询重复率很低,这种情况下使用查询缓冲反 而会影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。 |
49 | query_cache_limit | 1M | 4M | 8M | 16M | 32M | 32M | 指定单个查询能够使用的缓冲区大小,缺省为1M |
[myisamchk] | ||||||||
50 | sort_buffer_size | 2M | 16M | 32M | 64M | 128M | 256M | |
51 | key_buffer | 2M | 16M | 32M | 64M | 128M | 256M | |
52 | read_buffer | 1M | 8M | 16M | 32M | 64M | 128M | |
53 | write_buffer | 1M | 8M | 16M | 32M | 64M | 128M | |
[mysqldump] | ||||||||
54 | max_allowed_packet | 1M | 128M | 256M | 512M | 1024M | 2048M | mysql根据配置文件会限制server接受的数据包大小。 有时候大的插入和更新会被max_allowed_packet 参数限制掉,导致失败。 |
55 | ||||||||
[mysqld_safe] | ||||||||
56 | open-files-limit | 256 | 8192 | 8192 | 16384 | 16384 | 16384 | |
建议优化参数 | ||||||||
可以优化参数 |
MySQL 5.6参数优化详解
猜你喜欢
转载自blog.csdn.net/zhaofuqiangmycomm/article/details/106424057
今日推荐
周排行