zoukankan      html  css  js  c++  java
  • 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. 作为一个经验法则,日志文件的全部大小,应该足够容纳服务器一个小时的活动内容。 

  • 相关阅读:
    JQuery扩展方法
    RabbitMQ消息机制广播分发
    RabbitMQ消息机制单人分发
    对函数的参数求和
    ajax jsonp
    绑定函数bind()
    this 指向
    DOM兼容
    命名空间 namespace
    开始看编写高质量的代码
  • 原文地址:https://www.cnblogs.com/Jtianlin/p/5172459.html
Copyright © 2011-2022 走看看