目录
参数四：log_queries_not_using_indexes
学过Java的朋友都知道，随着学习和经验的深入，不可避免的要对jvm进行调参。MySQL数据库也是类似，随着运维经验逐渐增加，不可避免的也会关注起MySQL数据库的参数。
根据我个人运维MySQL数据库的经验，MySQL数据库学习总结为以下五个阶段。
MySQL数据库学习的五个阶段：
**阶段一：**关注MySQL数据库的安装部署，这个阶段主要关注MySQL的各种安装方式、安装部署相关的报错问题如何解决、安装过程中涉及到的重要参数作用、安装好之后连接数据库的各种报错问题。
**阶段二：**熟练掌握了MySQL数据库的安装部署之后，开始有精力关注MySQL数据库的常用运维操作，比如说建库建表、杀会话、简单sql性能分析、简单sql性能优化、故障浅层次分析，这一阶段也伴随着MySQL原理的学习，如innodb存储引擎、主从复制原理、高可用架构等。
**阶段三：**到了该阶段已经熟练掌握MySQL数据库的安装部署、各种架构搭建、基本运维方法、基本性能优化方法，并且有了一定的理论基础，关注点自然而然的转向更为复杂和有挑战的独立故障处理、独立性能分析，并且通过实践和理论不断交错印证，对MySQL数据库的认识会越发深入。
**阶段四：**该阶段对于MySQL数据库日常运维、常见故障、常见性能问题等都有了自己的思路，但随着理论和实践不断深入，更加意识到MySQL数据库还有很多内容需要掌握。并且视角也不仅仅局限在了数据库层面，排查问题和性能分析时，开始关注整个交易链路，如底层的OS、数据库层、网络层、交换机、负载均衡、应用层面，并且有精力开始了解和学习业务逻辑。在技术方面，又衍生出来很多问题，需要更加深入的探究数据库，于是开始探索源码。
**阶段五：**我目前还仅仅停留在阶段四，展望阶段五，对于故障分析和性能优化可以纵观全局，并且对于数据库的疑难杂症，也能得心应手的解决。且能根据应用情况，合理规划数据库架构和选型。
而不论在哪个阶段，MySQL数据库参数都是需要关注的。
介绍四个容易被忽略却又很重要的参数。
参数一：skip_slave_start
作用：MySQL实例启动时自动开启从库复制功能（值为0表示不跳过），适用于主从架构中的从库，确保实例重启后无需手动执行START SLAVE即可恢复复制。这个参数建议都设置为0，生产上的重要数据库肯定都会有同城灾备和异地灾备，当从库主动或者被动中断时，从库启动后，主从复制自动就能接上，除非从库停的时间超过主库binlog保留时间，那么就需要重做备机。
参数二：skip_name_resolve
作用：禁用MySQL对客户端IP地址的反向DNS解析功能；客户端连接时，MySQL不查询IP对应的主机名，直接使用IP地址验证权限，减少DNS解析开销和因DNS故障导致的连接延迟。生产上建议都开启这个参数，将值设置为1。避免DNS解析，可以减少相应时长，尤其是对耗时敏感的交易系统，更有必要。除此之外，打开这个参数，还能规避用户因为网络异常中断导致用户被block的情况，这就是我们马上要说的参数三了。
参数三：max_connect_errors
作用：在MySQL数据库关闭skip_name_resolve情况下，当数据库连接因为网络问题中断时，会累计错误次数，当错误次数达到max_connect_errors值时，用户连接数据库会报错block，需手动解锁。由于参数skip_name_resolve设置为on，故数据库不会因网络中断导致用户被锁。这个参数有时间再给大家重点演示一下，密码错误、权限失败并不会被累计到max_connect_errors的错误次数中，二十在已经建立连接，但因为网络突然中断情况下，该错误值会累计。
参数四：log_queries_not_using_indexes
log_queries_not_using_indexes作用：禁用记录未使用索引的查询（值为0表示关闭）；若开启（值为1），所有未使用索引的查询（即使执行时间短）都会被记录到慢查询日志，可能导致日志过大且包含大量非关键SQL。
log_throttle_queries_not_using_indexes 作用：设置未使用索引的查询日志的限流阈值，单位为每分钟；若开启log_queries_not_using_indexes，每分钟最多记录10条未使用索引的查询，避免日志被此类SQL淹没（当前log_queries_not_using_indexes 0，此参数暂不生效）。
这两个参数一般都是一起设置，如果生产上打开log_queries_not_using_indexes 参数，建议把log_throttle_queries_not_using_indexes参数也设置一个阈值。我曾经就遇到过一个单机MySQL数据库，打开了未使用索引的慢sql记录，但没有设置每分钟记录的阈值，而这个数据库又有很多未使用索引的sql，导致慢日志大小已经达到了183G，要分析慢日志就变得格外困难，并且慢日志分析的意义已经不是很大，干扰项太多。