mysql参数详解及其应用场景介绍

一、innodb_flush_log_at_trx_commit

这是关系到事务日志的一个参数,0或者2,只是定时的刷新到log buffer,

事务日志..不知道你明白不..就是你说的也影响到更新数据的操作.但对正常的数据读写不会有影响...简单来说..就是你事务提交了..,你就可以查到commit后的数据. 但这时并不一定写入到磁盘了..可能在缓存..

这个参数也就是在commit的时候会有差异,如果为1,就每个事务提交就会要刷新到磁盘后才算提交完成....这种情况是保证了事务的acid,但性能会有很大的影响...

如果为0或者2,只要commit了就算完成了...0和2的区别在于

0：当mysql挂了之后，可能会损失前一秒的事务信息

2：当mysql挂了之后，如果系统文件系统没挂，不会有事务丢失

个人建议设置成2

可以参考此文档http://blog.csdn.net/fengbangyue/article/details/6401564

二、skip-external-locking

MySQL的配置文件my.cnf中默认存在一行skip-external-locking的参数，即“跳过外部锁定”。根据MySQL开发网站的官方解释，External-locking用于多进程条件下为MyISAM数据表进行锁定。

如果你有多台服务器使用同一个数据库目录（不建议），那么每台服务器都必须开启external locking；

参数解释

当外部锁定（external-locking）起作用时，每个进程若要访问数据表，则必须等待之前的进程完成操作并解除锁定。由于服务器访问数据表时经常需要等待解锁，因此在单服务器环境下external locking会让MySQL性能下降。所以在很多Linux发行版的源中，MySQL配置文件中默认使用了skip-external-locking来避免external locking。

当使用了skip-external-locking后，为了使用MyISAMChk检查数据库或者修复、优化表，你必须保证在此过程中MySQL服务器没有使用需要操作的表。如果没有停止服务器，也至少需要先运行

1 mysqladmin flush-tables

命令，否则数据表可能出现异常。

参数使用说明

如果是多服务器环境，希望打开external locking特征，则注释掉这一行即可

1 # skip-external-locking

如果是单服务器环境，则将其禁用即可，使用如下语句

1 skip-external-locking

注意事项

在老版本的MySQL中，此参数的写法为：

1 skip-locking

如果在新版本MySQL配置中依然使用此写法，则可能出现：

[Warning] ‘–skip-locking’ is deprecated and will be removed in a future release. Please use ‘–skip-external-locking’ instead.

三、innodb_lock_wait_timeout

MySQL可以自动地监测行锁导致的死锁并进行相应的处理，但是对于表锁导致的死锁不能自动的监测，所以该参数主要被用于在出现类似情况的时候等待指定的时间后回滚。系统默认值是50秒，用户可以根据应用的需要进行调整。

四、log-bin

装mysql,运行一段时间后，在mysql目录下出现一堆类似mysql-bin.000***，从mysql-bin.000001开始一直排列下来，而且占用了大量硬盘空间，高达几十个G. 对于这些超大空间占用量的文件我们应该怎么办呢?

那么mysql数据库文件夹中的mysql-bin.00001是什么文件？

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

这些形如mysql-bin.00001的文件主要是用来做什么的呢?

1：数据恢复

如果你的数据库出问题了，而你之前有过备份，那么可以看日志文件，找出是哪个命令导致你的数据库出问题了，想办法挽回损失。

2：主从服务器之间同步数据

主服务器上所有的操作都在记录日志中，从服务器可以根据该日志来进行，以确保两个同步。

如果不想要这些文件应该怎么做呢?

1：只有一个mysql服务器，那么可以简单的注释掉这个选项就行了。

vi /etc/my.cnf把里面的 log-bin 这一行注释掉，重启mysql服务即可。

2：如果你的环境是主从服务器，那么就需要做以下操作了。

A：在每个从属服务器上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志。

B：使用SHOW MASTER LOGS获得主服务器上的一系列日志。

C：在所有的从属服务器中判定最早的日志，这个是目标日志，如果所有的从属服务器是更新的，就是清单上的最后一个日志。

D：清理所有的日志，但是不包括目标日志，因为从服务器还要跟它同步。

简单地说,这些MySQL目录下的形如mysql-bin.000***的文件时MySQL的事务日志。

删除复制服务器已经拿走的binlog是安全的，一般来说网络状况好的时候，保留最新的那一个足以。

(缺点是将无法使数据库恢复先前的状态)

五、innodb_buffer_pool_size

作用：

这个参数主要作用是缓存innodb表的索引，数据，插入数据时的缓冲

默认值：128M

专用mysql服务器设置的大小： 操作系统内存的70%-80%最佳。

设置方法：

my.cnf文件

innodb_buffer_pool_size = 6G

此外，这个参数是非动态的，要修改这个值，需要重启mysqld服务。

所以设置的时候要非常谨慎。

并不是设置的越大越好。设置的过大，会导致system的swap空间被占用，导致操作系统变慢，从而减低sql查询的效率。

六、innodb_thread_concurrency

InnoDB使用操作系统线程来处理用户事务请求，它是这样工作的：当InnoDB收到一个用户的请求时，如果已经超过innodb_thread_concurrency预先设置的并发线程数量，那么就会按照innodb_thread_sleep_delay预先设定的值休眠N秒，之后再次尝试连接，重试两次的机制是为了减少CPU上下文切换的次数，以降低CPU消耗。如果请求被接受了，则会获得一个innodb_concurrency_tickets默认500次的通行证，在这些次数用完之前，该线程重新请求时无须再进行前面所说的innodb_thread_concurrency的检查。如果还没有被接受，那么就会进入队列中，直到最终被处理掉。

从MySQL5.5.X版本开始，innodb_thread_concurrency被默认设置为0，表示不限制并发数，表1-2中是该参数的历史默认值。

表1-2　innodb_thread_concurrency参数默认值

InnoDB Version MySQL Version Default value Default limit of concurrent threads Value to allow unlimited threads

InnoDB Version MySQL Version Default value Default limit of concurrent threads Value to allow unlimited threads

Built-in Earlier than 5.1.11 20 No limit 20 or higher

Built-in 5.1.11 and newer 8 8 0

InnoDB storage engine before 1.0.3 (corresponding to Plugin) 8 8 0

InnoDB storage engine 1.0.3 and newer (corresponding to Plugin) 0 No limit 0

注意

innodb_thread_concurrency = 0时，innodb_thread_sleep_delay参数就无效了。同样innodb_concurrency_tickets也没了意义，这里推荐设置innodb_thread_concurrency为0，这样可以更好地发挥CPU多核处理能力，提高并发量。