my-innodb-heavy-4G.cnf1 详解

http://bbs.51cto.com/thread-1166608-1.html 在网上找的一篇

下面是自习找资料翻译的 欢迎讨论

1、 back_log = 50


#指定MySQL可能的连接数量。当MySQL主线程在很短的时间内得到非常多的连接请求,该参数就起作用,之后主线程花些时间(尽管很短)检查连接并且启动一个新线程。
  back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。如果系统在一个短时间内有很多连接,则需 要增大该参数的值,该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自己的限制。试图设定back_log高于 你的操作系统的限制将是无效的。
  当观察MySQL进程列表,发现大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时,就要加大 back_log 的值。back_log默认值为50。

max_connections = 100       
参数用来设置最大连接(用户)数。每个连接MySQL的用户均算作一个连接,max_connections的默认值为100
  
2、 max_connect_errors = 10


#当此值设置为10时,意味着如果某一客户端尝试连接此MySQL服务器,但是失败(如密码错误等等)10次,则MySQL会无条件强制阻止此客户端连接。
如果希望重置此计数器的值,则必须重启MySQL服务器或者执行
命令。
当这一客户端成功连接一次MySQL服务器后,针对此客户端的max_connect_errors会清零。
 影响与错误形式
如果max_connect_errors的设置过小,则网页可能提示无法连接数据库服务器;而通过SSH的mysql命令连接数据库,则会返回
ERROR 1129 (00000): Host ‘gateway’ is blocked because of many connection errors; unblock with ‘mysqladmin flush-hosts’

table_open_cache = 2048
参数设置表高速缓存的数目。每个连接进来,都会至少打开一个表缓存。因此, table_cache 的大小应与 max_connections 的设置有关。例如,对于 200 个并行运行的连接,应该让表的缓存至少有 200 × N ,这里 N 是应用可以执行的查询的一个联接中表的最大数量。此外,还需要为临时表和文件保留一些额外的文件描述符。
当 Mysql 访问一个表时,如果该表在缓存中已经被打开,则可以直接访问缓存;如果还没有被缓存,但是在 Mysql 表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区;如果表缓存满了,则会按照一定的规则将当前未用的表释放,或者临时扩大表缓存来存放,使用表缓存的好处是可以更快速地访问表中的内容。
缓存机制
当 Mysql 访问一个表时,如果该表在缓存中已经被打开,则可以直接访问缓存;如果还没有被缓存,但是在 Mysql 表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区;如果表缓存满了,则会按照一定的规则将当前未用的表释放,或者临时扩大表缓存来存放,使用表缓存的好处是可以更快速地访问表中的内容。
执行

mysql >flush tables;

#命令将会清空当前所有缓存的表。

3、 max_allowed_packet = 16M

#指代mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
这个是定义mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
定义过大,比如max_allowed_packet=8092,有可能服务器端太忙,来不及接收,或者网络太差,会容易造成丢包
定义过小,会因为客户端可能无法快速接收服务器端发过来的包,一般推荐是4096

http://bbs.chinaunix.net/thread-4178672-1-1.html

4、 binlog_cache_size = 1M
 #为每个session 分配的内存,在事务过程中用来存储二进制日志的缓存。提高记录bin-log的效率

max_heap_table_size = 64M
它规定了内部内存临时表的最大值,每个线程都要分配。(实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。)如果内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的MyISAM表,存储在指定的tmpdir目录下,默认:
mysql> show variables like "tmpdir";

5、read_buffer_size = 2M

#是MySQL读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySQL会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁,并且你认为频繁扫描进行得太慢,可以通过增加该变量值以及内存缓冲区大小提高其性能。
read_rnd_buffer_size = 16M
是MySQL的随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySQL会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大。

6、 sort_buffer_size = 8M

#是MySQL执行排序使用的缓冲大小。如果想要增加ORDER BY的速度,首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能,可以尝试增加sort_buffer_size变量的大小。
join_buffer_size = 8M
应用程序经常会出现一些两表(或多表)Join的操作需求,MySQL在完成某些 Join 需求的时候(all/index join),为了减少参与Join的“被驱动表”的读取次数以提高性能,需要使用到 Join Buffer 来协助完成 Join操作。当 Join Buffer 太小,MySQL 不会将该 Buffer 存入磁盘文件,而是先将Join Buffer中的结果集与需要 Join 的表进行 Join 操作,然后清空 Join Buffer 中的数据,继续将剩余的结果集写入此 Buffer 中,如此往复。这势必会造成被驱动表需要被多次读取,成倍增加 IO 访问,降低效率
thread_cache_size = 8
如果我们在MySQL服务器配置文件中设置了thread_cache_size,当客户端断开之后,
服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)。thread_cache_size功能在mysql数据库配置文件中是非常重要的一项功能了,如果对thread_cache_size优化做得好我们可以让服务器跑得非常快,设置不好就会发现很小访问量就非常的卡哦。
7、 thread_concurrency = 8

#是一个编程术语,表示“线程并发”,简单地说就是一个程序创建多个线程,并行执行一些任务。


query_cache_size = 64M
查询缓存保存查询返回的完整结果。当查询命中该缓存,会立刻返回结果,跳过了解析,优化和执行阶段。
查询缓存会跟踪查询中涉及的每个表,如果这写表发生变化,那么和这个表相关的所有缓存都将失效。
但是随着服务器功能的强大,查询缓存也可能成为整个服务器的资源竞争单点。
缓存存放在一个引用表中,通过一个哈希值引用,这个哈希值包括查询本身,数据库,客户端协议的版本等,任何字符上的不同,例如空格,注释都会导致缓存不命中。
当查询中有一些不确定的数据时,是不会缓存的,比方说now(),current_date(),自定义函数,存储函数,用户变量,字查询等。所以这样的查询也就不会命中缓存,但是还会去检测缓存的,因为查询缓存在解析SQL之前,所以MySQL并不知道查询中是否包含该类函数,只是不缓存,自然不会命中。

8、 query_cache_limit = 2M

#指定单个查询能够使用的缓冲区大小,缺省为1M

ft_min_word_len = 4
从 Mysql 4.0 开始就支持全文索引功能,但是 Mysql 默认的最小索引长度是 4。如果是英文默认值是比较合理的,但是中文绝大部分词都是2个字符,这就导致小于4个字的词都不能被索引,全文索引功能就形同虚设了
一般的数据 库搜索 都是用的SQL 的 like 语句,like 语句是不能利用索引的,每次查询都是从第一条遍历至最后一条,查询效率极其低下。一般数据超过10万或者在线人数过多,like查询都会导致数据库 崩溃。这也就是为什么很多程序 都只提供标题搜索的原因了,因为如果搜索内容,那就更慢了,几万数据就跑不动了。

     Mysql 全文索引是专门为了解决模糊查询提供的,可以对整篇文章 预先按照词进行索引,搜索效率高,能够支持百万级的数据检索。

9、 default-storage-engine = MYISAM
#默认的MyISAM存储引擎

10、 thread_stack = 192K
#每个连接被创建的时候,mysql分配给它的内存.这个值一般认为默认就可以应用于大部分场景了,除非必要非则不要动它.
transaction_isolation = REPEATABLE-READ
 


11、 tmp_table_size = 64M
#它规定了内部内存临时表的最大值,每个线程都要分配。(实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。)如果内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的MyISAM表,存储在指定的tmpdir目录下

log-bin=mysql-bin
mysql-bin.000001、mysql-bin.000002等文件是数据库的操作日志,例如UPDATE一个表,或者DELETE一些数据,即使该语句没有匹配的数据,这个命令也会存储到日志文件中,还包括每个语句执行的时间,也会记录进去的。

binlog_format=mixed
mysql复制主要有三种方式:基于SQL语句的复制(statement-based replication, SBR),基于行的复制(row-based replication, RBR),混合模式复制(mixed-based replication, MBR)。对应的,binlog的格式也有三种:STATEMENT,ROW,MIXED。
① STATEMENT模式(SBR)

每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化,减少了binlog日志量,节约IO,提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数, last_insert_id(),以及user-defined functions(udf)等会出现问题)

② ROW模式(RBR)

不记录每条sql语句的上下文信息,仅需记录哪条数据被修改了,修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志,尤其是alter table的时候会让日志暴涨。

③ MIXED模式(MBR)

以上两种模式的混合使用,一般的复制使用STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog,MySQL会根据执行的SQL语句选择日志保存方式
MIXED说明

对于执行的SQL语句中包含now()这样的时间函数,会在日志中产生对应的unix_timestamp()*1000的时间字符串,slave在完成同步时,取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步,而对于上面指定的一些类似于UDF函数,导致Slave无法知晓的情况,则会采用ROW格式存储这些Binlog,以保证产生的Binlog可以供Slave完成数据同步。
http://www.111cn.net/database/mysql/71702.htm
12、 slow_query_log

#顾名思义,慢查询日志中记录的是执行时间较长的query,也就是我们常说的slow query,通过设--log-slow-queries[=file_name]来打开该功能并设置记录位置和文件名,默认文件名为hostname-slow.log,默认目录也是数据目录。
    慢查询日志采用的是简单的文本格式,可以通过各种文本编辑器查看其中的内容。其中记录了语句执行的时刻,执行所消耗的时间,执行用户,连接主机等相关信息。MySQL还提供了专门用来分析满查询日志的工具程序mysqlslowdump,用来帮助数据库管理人员解决可能存在的性能问题。
http://www.cnblogs.com/Richardzhu/p/3230221.html

13、 long_query_time = 2

#MySQL慢查询支持毫秒的设置MySQL慢查询本身不支持ms级别(需要打补丁),但是对MySQL5.21+的版本,long_query_time最小值为0(5.2.1之前版本最小为1s),单位是s,如果指定ms,其ms部分会被忽略;其实这已经是变相支持毫秒级别了,比如查询时间大于100ms将被记
http://www.dedecms.com/knowledge/data-base/mysql/2012/0819/7319.html

14、 server-id = 1
#1、 mysql同步的数据中是包含server-id的,用于标识该语句最初是从哪个server写入的,因此server-id一定要有的


#2、 每一个同步中的slave在master上都对应一个master线程,该线程就是通过slave的server-id来标识的;每个slave在master端最多有一个master线程,如果两个slave的server-id 相同,则后一个连接成功时,前一个将被踢掉。 这里至少有这么一种考虑
      slave主动连接master之后,如果slave上面执行了slave stop;则连接断开,但是master上对应的线程并没有退出;当slave start之后,master不能再创建一个线程而保留原来的线程,那样同步就可能有问题;


#3、 在mysql做主主同步时,多个主需要构成一个环状,但是同步的时候有要保证一条数据不会陷入死循环,这里就是靠server-id来实现的
14、 key_buffer_size = 32M

#key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads /key_read_requests应该尽可能的低,至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得)。

key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表,但是内部的临时磁盘表是MyISAM表,也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。
http://blog.chinaunix.net/uid-24145780-id-125159.html

15、 bulk_insert_buffer_size = 64M

#和key_buffer_size一样,这个参数同样也仅作用于使用 MyISAM存储引擎,用来缓存批量插入数据的时候临时缓存写入数据。当我们使用如下几种数据写入语句的时候,会使用这个内存区域来缓存批量结构的数据以帮助批量写入数据文件:
http://www.jb51.net/article/48422.htm

16、 myisam_sort_buffer_size = 128M
#当对MyISAM表执行repair table或创建索引时,用以缓存排序索引;设置太小时可能会遇到” myisam_sort_buffer_size is too small”


17、 myisam_max_sort_file_size = 10G

#当对MyISAM表重建索引时(repair/alter table/load data infile),允许使用的临时文件最大值;如果超过此限制索引创建则改用key cache,此时show processlist会显示该线程处于”repair with keycache”而非”repair by sorting”,前者逐条创建索引记录;另外,当指定的tmpdir目录空间不足时也会导致类似情形;

18、 myisam_repair_threads = 1

# 如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复他们.
# 这对于拥有多个CPU以及大量内存情况的用户,是一个很好的选择.
myisam_recover
#自动检查和修复没有适当关闭的 MyISAM 表
19、 innodb_additional_mem_pool_size = 16M

#这个参数用来设置 InnoDB 存储的数据目录信息和其它内部数据结构的内存池大小,类似于Oracle的library cache。这不是一个强制参数,可以被突破。
innodb_buffer_pool_size = 2G
当我们使用InnoDB存储引擎的时候,innodb_buffer_pool_size 参数可能是影响我们性能的最为关键的一个参数了,他用来设置用于缓存 InnoDB 索引及数据块的内存区域大小,类似于 MyISAM 存储引擎的 key_buffer_size 参数,当然,可能更像是 Oracle 的 db_cache_size。简单来说,当我们操作一个 InnoDB 表的时候,返回的所有数据或者去数据过程中用到的任何一个索引块,都会在这个内存区域中走一遭。

    和key_buffer_size 对于 MyISAM 引擎一样,innodb_buffer_pool_size 设置了 InnoDB 存储引擎需求最大的一块内存区域的大小,直接关系到 InnoDB存储引擎的性能,所以如果我们有足够的内存,尽可将该参数设置到足够打,将尽可能多的 InnoDB 的索引及数据都放入到该缓存区域中,直至全部。

    我们可以通过 (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率,并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。
innodb_data_file_path = ibdata1:10M:autoextend
#表空间文件 重要数据
20、 innodb_write_io_threads = 8
#其它对IO有影响的参数(以5.6为准)
innodb_adaptive_flushing 默认即可
innodb_change_buffer_max_size 如果是日值类服务,可以考虑把这个增值调到 50
innodb_change_buffering 默认即可
innodb_flush_neighors 默认是开的, 这个一定要开着,充分利用顺序IO去写数据。
innodb_lru_scan_depth: 默认即可 这个参数比较专业。
innodb_max_purge_lag 默认没启用,如果写入和读取都量大,可以保证读取优先,可以考虑使用这个功能。
innodb_random_read_ahead 默认没开启,属于一个比较活跃的参数,如果要用一定要多测试一下。 对用passport类应用可以考虑使用
innodb_read_ahead_threshold 默认开启:56 预读机制可以根据业务处理,如果是passprot可以考虑关闭。如果使用innodb_random_read_ahead,建议关闭这个功能
innodb_read_io_threads 默认为:4 可以考虑8
innodb_write_io_threads 默认为:4 可以考虑8
sync_binlog 默认即可: 0
innodb_rollback_segments 默认即可: 128

另外5.6的undo log也可以独立配置了,建议单独配置出来。
http://www.mysqlsupport.cn/innodb-io-optimize-conf

21、 innodb_read_io_threads = 8
#文件IO的线程数,一般为 4,但是在 Windows 下,可以设置得较大。
22、 innodb_thread_concurrency = 16
#服务器有几个CPU就设置为几,建议用默认设置,一般为8.
23 、innodb_flush_log_at_trx_commit = 1
# 如果将此参数设置为1,将在每次提交事务后将日志写入磁盘。为提供性能,可以设置为0或2,但要承担在发生故障时丢失数据的风险。设置为0表示事务日志写入日志文件,而日志文件每秒刷新到磁盘一次。设置为2表示事务日志将在提交时写入日志,但日志文件每次刷新到磁盘一次。
24、 innodb_log_buffer_size = 8M
#这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer,InnoDB 在写事务日志的时候,为了提高性能,也是先将信息写入 Innofb Log Buffer 中,当满足 innodb_flush_log_trx_commit 参数所设置的相应条件(或者日志缓冲区写满)之后,才会将日志写到文件(或者同步到磁盘)中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。
注:innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0,1,2,解释如下:

0:log buffer中的数据将以每秒一次的频率写入到log file中,且同时会进行文件系统到磁盘的同步操作,但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作;
1:在每次事务提交的时候将log buffer 中的数据都会写入到log file,同时也会触发文件系统到磁盘的同步;
2:事务提交会触发log buffer 到log file的刷新,但并不会触发磁盘文件系统到磁盘的同步。此外,每秒会有一次文件系统到磁盘同步操作。

此外,MySQL文档中还提到,这几种设置中的每秒同步一次的机制,可能并不会完全确保非常准确的每秒就一定会发生同步,还取决于进程调度的问题。实际上,InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制,可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。
25、 innodb_log_file_size = 256M
#此参数确定数据日志文件的大小,以M为单位,更大的设置可以提高性能,但也会增加恢复故障数据库所需的时间
26、 innodb_log_files_in_group = 3

#为提高性能,MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3M
27、 innodb_max_dirty_pages_pct = 90

# Buffer_Pool中Dirty_Page所占的数量,直接影响InnoDB的关闭时间。参数innodb_max_dirty_pages_pct 可以直接控制了Dirty_Page在Buffer_Pool中所占的比率,而且幸运的是innodb_max_dirty_pages_pct是可以动态改变的。所以,在关闭InnoDB之前先将innodb_max_dirty_pages_pct调小,强制数据块Flush一段时间,则能够大大缩短 MySQL关闭的时间。
http://www.taobaodba.com/html/221_innodb_max_dirty_pages_pct_checkpoint.html

28、 innodb_lock_wait_timeout = 120
# InnoDB 有其内置的死锁检测机制,能导致未完成的事务回滚。但是,如果结合InnoDB使用MyISAM的lock tables 语句或第三方事务引擎,则InnoDB无法识别死锁。为消除这种可能性,可以将innodb_lock_wait_timeout设置为一个整数值,指示 MySQL在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)
[mysqldump]
Quick 
 = 16M
指代mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
这个是定义mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
定义过大,比如max_allowed_packet=8092,有可能服务器端太忙,来不及接收,或者网络太差,会容易造成丢包
定义过小,会因为客户端可能无法快速接收服务器端发过来的包,一般推荐是4096
 [mysql]
no-auto-rehash
是自动补全的意思,就像我们在linux命令行里输入命令的时候,使用tab键的功能是一样的

[myisamchk]
29、 key_buffer_size = 512M

#如果key_buffer_size设置太大,系统就会频繁的换页,降低系统性能。因为MySQL使用操作系统的缓存来缓存数据,所以我们得为系统留够足够的内存;在很多情况下数据要比索引大得多
http://www.cnblogs.com/sunss/archive/2011/03/11/1981373.html

30、 sort_buffer_size = 512M
#1 Sort_Buffer_Size 是一个connection级参数,在每个connection第一次需要使用这个buffer的时候,一次性分配设置的内存。
#2 Sort_Buffer_Size 并不是越大越好,由于是connection级的参数,过大的设置+高并发可能会耗尽系统内存资源。
#3 文档说“On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation”
http://bbs.chinaunix.net/thread-1805254-1-1.html

31、 read_buffer = 8M
#主要用于表顺序扫描的缓存,这个缓存的作用是不是多次查询同一张表不用去磁盘取数据,直接从缓存中读取(这里有个疑问,如果数据发生了修改了缓存就会失效?),还是仅仅只是作为一次全表扫描的缓存,查询完缓存空间直接释放了,不会用于下一次查询。
http://bbs.csdn.net/topics/390415865?page=1

32、 write_buffer = 8M
#cache和write buffer都是内置于CPU内部的一小段高速存储器,cache中保存着最近一段时间被CPU使用过的内存数据,而write buffer则是用来应对内存的写操作的,将原本要写向内存的数据暂写到write buffer中,等到CPU空闲的时候,数据才会慢慢地被搬移到内存里。
http://blog.chinaunix.net/uid-20662820-id-3917558.html

[mysqlhotcopy]
interactive-timeout
interactive_timeout是MySQL在等待一个活动连接关闭连接前等待的秒数
http://blog.itpub.net/26855487/viewspace-751504

[mysqld_safe]
open-files-limit = 8192
MySQL的变量open_files_limit,table_open_cache和max_connections是相互关联的。如果对有些变量进行了设置,有的变量没有设置,mysql会根据一定的计算公式进行计算得出其他的,当然有些时候会触发mysql的一些警告来。具体的计算流程及如何得出最终的文件描述符有些许复杂
http://www.sudops.com/mysql-open-file-limit-max_connections-table-open-cache.html

 

你可能感兴趣的:(my-innodb-heavy-4G.cnf1 详解)