Mysql一些重要配置参数的学习与整理（二）

    原文地址：Mysql一些重要配置参数的学习与整理（二）

   上一篇，Mysql一些重要配置参数的学习与整理（一）中，我们了解和学习了mysql配置中的一些重要参数，今天继续进行学习，mysql的配置参数很多，不可能做到面面俱到，这里的总结和整理只是针对于现实生产环境中用到的一些配置参数的学习，接下来，开始本篇的学习。

   innodb_flush_log_at_trx_commit = 2   

    这个变量的官方定义是：Controls the balance between strict ACID compliance for commit operations，and higher performance  that is possible when commit-related I/O operations are rearranged and done in batches。我自己的理解是用于控制两种关系之间的平衡，这两种关系：提交操作严格的ACID特性，提交相关的IO操作被分批的重新排列和完成时可能带来的高性能。你可以通过修改这个变量的默认值达到更好的性能，但是你可能会在意外崩溃时丢失一秒的事务。

• 默认值为 1 完全符合数据库ACID特性，这个值表示，在每次事务提交的时候，InnoDB日志缓冲区的内容都会被写入到日志文件，并且日志文件会被刷新到磁盘。

• 如果变量值为0，则表示InnoDB日志缓冲区的内容大约每秒被写入日志文件一次，并且日志文件会被刷新到磁盘。那些日志缓冲区中没有写入的内容会在事务提交的时候被写入日志文件。由于进程调度的问题，每秒的刷新并不能100%保证每一秒都发生。由于刷新磁盘的操作只有大约每秒才发生一次，所以在任何mysqld进程崩溃的时候，你都会丧失一秒的事务。
  

• 如果变量值为2，则表示InnoDB日志缓冲区的内容会在事务提交的时候写入到日志文件，并且日志文件会大约每秒刷新一次磁盘。同样的，由于进程调度的问题，每秒的刷新并不能100%保证每一秒都发生。由于刷新磁盘的操作只有大约每秒才发生一次，所以在操作系统崩溃或突然断电的时候，你都会丧失一秒的事务数据。

• 在MySQL 5.6.6版本中，InnoDB日志刷新频率由变量innodb_flush_log_at_timeout,控制，它允许你将日志刷新频率设置为N秒（默认值是1，可以设置1到2700之间的整数值），但是任何mysqld进程的崩溃都会清除高达N秒的事务数据。

• DDL变化和其他内部InnoDB的活动，则是独立的innodb_flush_log_at_trx_commit设置进行InnoDB日志刷新。
  

• InnoDB的崩溃恢复机制是不管变量innodb_flush_log_at_trx_commit的设置的，事务要么全部应用，要么全部删除。

    根据数据库应用设置的持久性和一致性，建议参考如下方式进行InnoDB事务设置：

• 如果启用了二进制日志，设置sync_binlog=1。

• 总是设置innodb_flush_log_at_trx_commit=1。

    这么建议的原因是：许多操作系统和一些磁盘硬件愚弄刷新到磁盘的操作，他们可能会告诉mysqld：刷新操作已经发生，但是事实上并没有发生。然后事务的持久性即使设置为1，也不能得到保证。在最糟糕的情况突然断电甚至会造成InnoDB数据的损坏。在SCSI磁盘控制器或本身加速文件刷新的磁盘上使用电池支持的磁盘缓存，会使操作更安全。你也可以尝试使用Unix命令hdparm禁用磁盘写入缓存的硬件高速缓存，或使用特定的硬件供应商提供的其他一些命令。
    

    sync_binlog   

    如果这个变量的值大于0，MySQL服务器会在sync_binlog提交组被写入到二进制日志之后，使用fdatasync()命令同步二进制日志到磁盘。默认的sync_binlog变量值为0，表示不同步到磁盘。mysql服务器依赖于操作系统不时的刷新二进制文件的内容，用于任何其他文件。值为1是最安全的选择，因为在崩溃的情况下你最多从二进制日志丢失一个提交组。然而，它也是最慢的选择（除非你你的磁盘具有电池备份缓存，这会使得同步非常快）。

   innodb_lock_wait_timeout = 20   

    表示InnoDB事务从等待获取行锁到放弃的时间长度，默认的值为50秒。一个事务试图获取被另一个InnoDB事务锁定的行所等待的最大时间，超时时会发出以下错误信息：
    ERROR 1205 (HY000)： Lock wait timeout exceeded； try restarting transaction（锁等待超时，试图重启事务）

    当锁等待超时后，当前的语句会回滚（并不是整个事务回滚）。如果需要整个事务都回滚，需要在服务器启动时通过innodb_rollback_on_timeout参数设置。

    在高度交互的应用程序或OTLP系统中，为了更好的用户反馈或将更新放入一个队列等待后续处理，你可能会减小该变量值。对于长期运行的后端操作，比如在一个数据仓库中存在大批量的插入或更新操作等待完成时，你可能会增加该值。

    innodb_lock_wait_timeout仅适用于InnoDB的行级锁。一个MySQL表锁不会发生在InnoDB，这个参数并不适用于等待表锁。

    锁等待超时值不适用于死锁，因为在事务死锁时，InnoDB会立即检测到它们并事务回滚。

    innodb_lock_wait_timeout可以在运行时，通过SET GLOBAL或SET SESSION声明进行设置。修改全局的设置需要SUPER权限，并会影响接下来所有连接客户端的操作。任何客户端都可以在SESSION会话级别设置innodb_lock_wait_timeout，它只会影响到该客户端。

    至此，线上mysql服务器上的配置文件参数已经全部做了整理，对于这些参数也有了一定的认识和了解，接下来，对于经常使用到的connections变量做一下整理，为接下来与同事讨论mysql的优化及设置做些准备，主要是以下几个connections变量：
   max_connections    

    系统变量，它表示最大允许的并发客户端连接数，会影响在服务器上运行的线程数量，默认值是151，增加该值会增加mysqld请求的文件描述符的数量。如果所请求的描述符的数量不可用，服务器会减少max_connections的值。连接拒绝是因为，max_connections的最大值，达到了Connection_errors_max_connections状态变量的增量。
    上一篇，Mysql一些重要配置参数的学习与整理（一）中学习的 thread_cache_size 变量的默认值就与max_connections有关。

   max_user_connections    

    表示允许任何给定的MySQL用户帐户同时连接的最大数目。默认值为0表示不限制。此变量可以在服务器启动时或运行时设置一个全局值。它也有一个只读会话值，表示与当前会话相关联的帐户的有效同时连接的限制值。会话级别的max_user_connections初始化如下：

• 如果用户帐户具有非零的MAX_USER_CONNECTIONS资源限制（帐户的资源限制通过GRANT语句指定），会话级别的MAX_USER_CONNECTIONS值就设为该限制。

• 否则的话，会话级别的MAX_USER_CONNECTIONS的值会被设置为全局值。

   Connection_errors_max_connections   

    表示当服务器中连接数达到max_connections的限制后，连接数被拒绝的数量。

     Connections                  

     表示尝试连接到mysql服务器的数量，无论成功或失败。

     Max_used_connections     

    从服务器启动开始，已同时被使用的最大连接数。