【转】生产环境MySQL Server核心参数的配置

 

   ⑴ lower_case_table_names

      

      ● 推荐理由

         

         GNU/Linux 平台，对数据库、表、存储过程等对象名称大小写敏感

         为减少开发人员的开发成本，为此推荐大家设置该参数使对象名称都自动转换成小写

      

      ● 参数介绍

         

         取值范围：

         为0：区分大小写、Linux 平台默认值

         为1：不区分大小写

         

         Linux安装的MySQL的配置文件中(/etc/my.cnf)、是没有lower_case_table_names=1这行的

         在Windows安装的MySQL的配置文件中(my.ini)、是有lower_case_table_names=1这行的

         

         所以、特别提醒下、在 Replication 配置下、Master和Slave中该参数应当保持一致！！

    

    

         

   ⑵ max_connect_errors

      

      ● 推荐理由

         

         一台物理服务器只要连接 MySQL 数据库服务器 异常中断累计超过10次，就再也无法连接上mysqld服务

         为此建议大家设置此值至少大于等于10

         处理方案有 2 ：

         要么重启mysqld、要么 mysqladmin flush-hosts

         

      ● 参数介绍 

         

         不过、该参数和安全相关、

         某些黑客或许会尝试失败来暴力破解密码、该值如若设置过大会留下可趁之际

         

         

         

   ⑶ interactive_timeout和wait_timeout

      

      ● 推荐理由

         

         如果你的MySQL Server有大量的闲置连接，他们不仅会白白消耗内存，而且如果连接一直在累加

         那么、最终肯定会达到MySQL Server的连接上限数，这会报'too many connections'的错误

         

         推荐值：

         inactive_timeout=172800

         wait_timeout=172800

         

      ● 参数介绍

         

         interactive_timeout

         参数含义：服务器关闭交互式连接所等待的秒数

         wait_timeout

         参数含义：服务器关闭非交互式连接所等待的秒数

         

         

         

   ⑷ transaction-isolation和binlog-format

      

      推荐配置

 

      ▼只读为主的业务应用场景

        

        transaction-isolation=read-commited

        binlog-format=mixed

        

      ▼非只读为主的业务应用场景

        

        transaction-isolation=repeatabled-read

        binlog-format=mixed 

        

        

      

   ⑸ innodb_adaptive_hash_index

      

      ● 推荐理由

         

         InnoDB引擎会根据数据的访问频繁度，把表的数据逐渐缓到内存，若是一张表的数据大量缓存在内存中

         则使用 HASH Index 会更高效

         InnoDB内有Hash Index机制，监控数据的访 问情况，可以自动创建和维护一个Hash Index

         

         

         

   ⑹ innodb_max_dirty_pages_pct

      

      ● 推荐理由

         

         InnoDB较之MyISAM，一个重要特性是InnoDB会在内存中开辟一个Buffer Pool来存储最近访问的数据块/索引块

         使得下次再次访问这个块时速度能够很快、当InnoDB对需要修改数据块的时候

         会先记录修改日志，然后直接对Buffer_Pool中的数据块的操作

         记录日志是顺序写，对数据块的操作是内存操作，这让InnoDB在很多场景下有这很好的速度优势

         上面对内存块修改完成后，InnoDB就向客户端返回了

         可这时实际磁盘上的数据块，还并没有被更新，我们把这样的page称为Dirty Page

         在InnoDB的后台有一个专门的线程来做将内存数据块Flush到磁盘的工作

         参数innodb_max_dirty_pages_pct可以直接控制了Dirty_Page在Buffer_Pool中所占的比率

         一般范围建议设置为5%~90%

         比例设置较小，有利于减少mysqld服务出现问题的时候恢复时间，缺点则是需要更多的物理I/O

         

      ● 参数介绍

         

         innodb_max_dirty_pages_pct与检查点的关系

         show innodb status\G;查看检查点位置

         减小innodb_max_dirty_pages_pct、会增加检查点事件发生的频率、从而减少脏页数量

         生产环境中、我们经常发现：

         数据库运行一段时间后，经常导致服务器大量的swap

         有可能是innodb中的脏数据太多了，因为没有free space了，mysql通知OS，把一些脏页交换出去

         那么我们可尝试减小innodb_max_dirty_pages_pct

         

         

         

   ⑺ innodb_commit_concurrency

      

      ● 推荐理由

         

         参数含义：同一时刻，允许多少个线程同时提交InnoDB事务，默认值为0，范围0-1000

         0：允许任意数量的事务在同一时间点提交

         N>0：允许N个事务在同一时间点提交

         不过、在mysqld提供服务时、不允许把非0改为0或者把0改为非0、但可以在两个非0值之间进行变更

         

         

         

   ⑻ innodb_fast_shutdown  and innodb_force_recovery

      

      ● 推荐理由

         

         innodb_fast_shutdown

         参数含义：设置innodb引擎关闭的方式，默认值为：1，正常关闭的状态

         0：mysqld服务关闭前，先进行数据完全的清理和插入缓冲区的合并操作

               若是脏数据较多或者服务器性能等因素，会导致此过程需要数分钟或者更长时间

         1：正常关闭mysqld服务，针对innodb引擎不做任何其他的操作

         2：若是mysqld出现崩溃，立即刷事务日志到磁盘上并且冷关闭mysqld服务

               没有提交的事务将会丢失，但是再启动mysqld服务的时候会进行事务回滚恢复

            

         innodb_force_recovery

         参数含义：mysqld服务出现崩溃之后，InnoDB引擎进行回滚的模式，默认值为0，可设置的值0~6

         0：正常的关闭和启动，不会做任何强迫恢复操作

         1：跳过错误页，让mysqld服务继续运行。跳过错误索引记录和存储页，尝试用：

               SELECT *  INOT OUTFILE ‘../filename’ FROM tablename;方式，完成数据备份

         2：阻止InnoDB的主线程运行。清理操作时出现mysqld服务崩溃，则会阻止数据恢复操作

         3：恢复的时候，不进行事务回滚

         4：阻止INSERT缓冲区的合并操作。不做合并操作，为防止出现mysqld服务崩溃。不计算表的统计信息

         5：mysqld服务启动的时候不检查回滚日志：InnoDB引擎对待每个不确定的事务就像提交的事务一样

         6：不做事务日志前滚恢复操作

         

         推荐的参数组合配置：

         innodb_fast_shutdown = 1

         #若是机房条件较好可设置为0（双路电源、UPS、RAID卡电池和供电系统稳定性）

         innodb_force_recovery =0

         #至于出问题的时候，设置为何值，要视出错的原因和程度，对数据后续做的操作

         

         

         

         

   ⑼ innodb_additional_mem_pool_size

      

      ● 推荐理由

         

         参数含义：开辟一片内存用于缓存InnoDB引擎的数据字典信息和内部数据结构（比如：自适应HASH索引结构）

         默认值：build-in版本默认值为：1M；Plugin-innodb版本默认值为：8M；

         

         若是mysqld服务上的表对象数量较多，InnoDB引擎数据量很大，且innodb_buffer_pool_size的值设置较大

         则应该适当地调整innodb_additional_mem_pool_size的值

         若是出现缓存区的内存不足，则会直接向OS申请内存分配，并且会向MySQL的error log文件写入警告信息

         

         

         

   ⑽ innodb_buffer_pool_size

      

      ● 推荐理由

         

         参数含义：开辟一片内存用于缓存InnoDB引擎表的数据和索引

         参数最大值：受限于CPU的架构，支持32位还是支持64位，另外还受限于OS为32位还是64位

         

         innodb_buffer_pool_size的值设置合适，会节约访问表对象中数据的物理IO

         

         InnoDB占用的内存，除innodb_buffer_pool_size用于存储页面缓存数据外，另外正常情况下还有大约8%的开销

         主要用在每个缓存页帧的描述、adaptive hash等数据结构，如果不是安全关闭，启动时还要恢复的话

         还要另开大约12%的内存用于恢复，两者相加就有差不多21%的开销

         所以、在分配innodb_buffer_pool_size时应该多加留意

         

         对于一个专用的DB,理论上可以分到60%-80%的内存给DB.  分到60%-80%是不是就OK了,就不用管了.当然不是了

         是不是合适,可以通过show engine innodb status\G; 查看命中情况. 当命中没达到97%以上,都可以考虑加内存

         

         在保证系统不宕机，不发生内存溢出(OOM)，不发生严重内存swap，给myisam、其他应用及系统预留一定份额前提下

         给innodb分配的buffer越大越好，浪费就浪费点，早晚都能用上的，谁让内存越来越便宜了呢

         

         

         

         

   ⑾ innodb_flush_log_at_trx_commit  AND  sync_binlog

      

      ● 推荐理由

         

         innodb_flush_log_at_trx_commit = N

         N=0  – 每隔一秒，把事务日志缓存区的数据写到日志文件中，以及把日志文件的数据刷新到磁盘上

         N=1  – 每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上

         N=2  – 每事务提交的时候，把事务日志数据从缓存区写到日志文件中；每隔一秒，刷新一次日志文件

                     但不一定刷新到磁盘上，而是取决于操作系统的调度

         

         sync_binlog =  N

         N>0  — 每向二进制日志文件写入N条SQL或N个事务后，则把二进制日志文件的数据刷新到磁盘上

         N=0  — 不主动刷新二进制日志文件的数据到磁盘上，而是由操作系统决定

         

         

         推荐配置组合：

         N=1,1  — 适合数据安全性要求非常高，而且磁盘IO写能力足够支持业务，比如充值消费系统

         N=1,0  — 适合数据安全性要求高，磁盘IO写能力支持业务不富余，允许备库落后或无复制

         N=2,0或2,m(0<m<100)  — 适合数据安全性有要求，允许丢失一点事务日志，复制架构的延迟也能接受

         N=0,0  — 磁盘IO写能力有限，无复制或允许复制延迟稍微长点能接受，例如：日志性登记业务

         

         

         

   ⑿ innodb_file_per_table

      

      ● 推荐理由

         

         参数含义：每个表一个表空间

         如果设置了便可以明确知道innodb表究竟占多大空间了

         表备份方便了,删除能回收空间

         

         如果是共享表空间， 当你的表多，表空间会撑得很大； 当然随着表的删除，也会留下不少空隙

         如果是独立表空间， 在做数据维护的时候也会特别清晰，比如alter table ， 结束后会把临时产生的空间释放；

         而如果是共享表空间，临时扩大的空间，是不会及时收缩的、可能会存在大量碎片

         

         共享表空间在Insert操作上稍有优势。其它都没独立表空间表现好

         

         

         

   ⒀ key_buffer_size

      

      ● 推荐理由

         

         对于我们只使用InnoDB引擎的数据库系统而言，此参数值也不能设置过于偏小

         因为临时表可能会使用到此键缓存区空间，索引缓存区推荐：64M

         

         

         

   ⒁ query_cache_type和query_cache_size

      

      ● 推荐理由

         

         query_cache_type=N

         

         N=0  —- 禁用查询缓存的功能

         N=1  —- 启用产讯缓存的功能，缓存所有符合要求的查询结果集，除SELECT SQL_NO_CACHE..， 

                        以及不符合查询缓存设置的结果集外

         N=2  —- 仅仅缓存SELECT SQL_CACHE …子句的查询结果集，除不符合查询缓存设置的结果集外

         

         query_cache_size

         

         查询缓存设置多大才是合理？至少需要从四个维度考虑：

         ①   查询缓存区对DDL和DML语句的性能影响；

         ②   查询缓存区的内部维护成本；

         ③   查询缓存区的命中率及内存使用率等综合考虑

         ④   业务类型

         

         query_cache_size的工作原理：

         一个SELECT查询在DB中工作后，DB会把该语句缓存下来，当同样的一个SQL再次来到DB里调用时，

         DB在该表没发生变化的情况下把结果从缓存中返回给Client

         

         这里有一个关建点，就是DB在利用Query_cache工作时，要求该语句涉及的表在这段时间内没有发生变更

         那如果该表在发生变更时，Query_cache里的数据又怎么处理呢？

         首先要把Query_cache和该表相关的语句全部置为失效，然后在写入更新

         那么如果Query_cache非常大，该表的查询结构又比较多，查询语句失效也慢，一个更新或是Insert就会很慢

         

         所以在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建系把该功能禁掉

　

源：http://www.2cto.com/database/201305/208122.html