mysql笔记05 优化服务器设置

优化服务器设置

1. MySQL有大量可以修改的参数--但不应该随便去修改。通常只需要把基本的项配置正确(大部分情况下只有很少一些参数时真正重要的)，应将更多时间花在schema的优化、索引，以及查询设计上。

在正确配置了MySQL的基本配置项之后，再花力气去修改其他配置项的收益通常就比较小。

从另一方面来说，没用的配置导致潜在风险的可能更大。

2. 那么什么是该做的呢？

确保基本配置是正确的。例如InnoDB的Buffer Pool和日志文件缓存大小，如果想防止出问题(提醒一下，这样做通常不能提升性能--它们只能避免问题)，就设置一个比较安全的值，剩下的配置就不用管了。

3. 另一个节省时间和避免麻烦的好办法是使用默认配置，除非是明确地知道默认值会有问题。很多人都是在默认配置下运行的，这种情况非常普遍。这使得默认配置经过最多的实际测试的。对配置项做一些不必要

的修改可能会遇到一些意料之外的bug.

4. MySQL配置的工作原理：

    1). 配置文件位置一般在/etc/my.cnf或者/etc/mysql/my.cnf

    2). 任何打算长期使用的配置都应该写到全局配置文件中。

4.3 入门

1). 设置变量时请小心，并不是值越大越好，而且如果设置的值太高，可能更容易导致问题：可能会由于内存不足导致服务器内存交换，或者超过地址空间。

   2). 应该始终通过监控来确认生产环境中变量的修改，是提高还是降低了服务器的整体性能。

 3). 如果你经常做笔记，在配置文件中写好注释，可能会节省自己(和同时)大量的工作。一个更好的主意是把配置文件置于版本控制之下。

4). 在开始改变配置之前，应该优化查询和schema，至少先做明显要做的事情，例如添加索引。如果先深入调整配置，然后修改了查询语句和schema，也许需要回头再次评估配置。

4.4 通过基准测试迭代优化

1). 一般情况下不建议做大量的基准测试，收益太少，并且可能会掩盖其他问题。而把时间花在检查备份、监控执行计划的变动之类的事情上，可能会更有意义。

2). 如果必须这样做，我们建议在开始配置服务器之前，开发一份定制的基准测试包。

 3). 最好的办法是一次改变一个或者两个变量，每次一点点，每次更改后运行基准测试，确保运行足够长的时间来确认性能是否稳定。

5. 什么不该做：

1). 不要根据一些"比率" 来调优。例如：如果命中率低，则应该增加缓存大小。这在很多情况下都是错误的。

2). 不要使用调优脚本。有几个这样的可以在互联网上找到的脚本非常受欢迎，最好忽略它们。

3). 在互联网上搜索如何配置并不总是一个好主意。在博客、论坛等地方都可以能知道到很多不好的建议。

    4). 不要相信很溜的内存消耗公式--是的，就是MySQL崩溃时自身输出的那个内存消耗公式。这个公式已经很老了，他可能并不靠谱。

6. 创建配置文件：

9. InnoDB在大多数情况下如果如果要运行得很好，配置大小合适的缓冲池(Buffer Pool)和日志文件(Log File)是必须的，默认值都太小了。其他的所有InnoDB设置都是可选的。

1). 设置缓冲池的大小。

a. 从服务器内存总量开始。

b. 减去操作系统的内存占用，如果MySQL不是唯一运行在这个服务器上的程序，还要扣掉其他程序可能占用的内存。

c. 减去一些MySQL自身需要的内存，例如为每个查询操作分配的一些缓冲。

d. 减去足够让操作系统缓存InnoDB日志文件的内存，至少是足够缓存最近经常访问的部分(此建议适用于标准的MySQL,Percona Server可以配置日志文件用O_DIRECT方式打开，绕过操作系统缓存)。，留一些

内存至少可以缓存二进制日志的最后一部分也是很好的选择，尤其是如果复制产生了延迟，备库就可能读取主库上旧的二进制日志文件，给主库的内存造成一些压力。

e. 减去其他配置的MySQL缓冲和缓存需要的内存，例如MyISAM的键缓存(key Cache)，或者查询缓存(Query Cache)。

f. 除以105%，这差不多接近InnoDB管理缓冲池增加的自身管理开销。

g. 把结果四舍五入，向下去一个合理的数值。向下舍入不会太影响结果，但是如果分配太多可能就会是件很糟糕的事情。

我们建议，当配置内存缓存区的时候，宁可谨慎，而不是把它们配置的过大。如果把缓冲池配置的比它可以设的值少了20%，很可能只会对性能产生小的影响，

         也许就只影响几个百分点。如果设置的大了20%，则可能会造成更严重的问题：内存交换、磁盘抖动、甚至内存耗尽和硬件死机。

2). 设置日志文件大小：

a. 整体的日志文件大小受控于innodb_log_file_size和inoodb_log_files_in_group两个参数，这对写性能非常重要。日志文件的总大小是每个文件的大小之和。默认情况下，只有两个5M的文件，总共10M。对于

高性能工作来说这太小了。至少需要几百M，或者甚至上GB的日志文件。

b. InnoDB使用多个文件作为一组循环日志。通常不需要修改默认的日志数量，只修改每个日志文件的大小即可。要修改日志文件大小，需要完全关闭MySQL，将旧的日志文件移到其他地方保存，重新配置参数，然后重启。

一定要保证MySQL干净地关闭了，或者还有日志文件可以保证应用到数据文件的事务记录，否则数据库就无法恢复了！当重启服务器的时候，查看MySQL的错误日志。在重启成功后，才可以删除旧的日志文件。

c. 通常不需要把日志缓存区设置的非常大。推荐范围是1MB-8MB，一般来说足够了，除非要写很多相当大的BLOG记录。

    d. 作为一个经验法则，日志文件的全部大小，应该足够容纳服务器一个小时的活动内容。