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     

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