MySQL监控调优

影响MySQL性能的原因总结一下，主要如下：

• 服务器硬件；

  • CPU：
    • 64位的CPU一定要工作在64位的系统下；
    • 对于并发比较高的场景，CPU的数量比频率更重要；
    • 对于密集型场景和负责SQL，则CPU频率越高越好
  • 内存：
    • 选择主板所能使用的最高频率的内存；
    • 内存的大小对于性能很重要，所以尽可能的大；

• 网卡流量；

• 磁盘IO；

• SQL查询速度；

Mysql 的查询过程

1. 先查询缓存，检查query语句是否完全匹配，接着在检查是否具有权限，都成功则直接取数据返回；
2. 上一步有失败则转交给‘命令解析器’，经过词法分析，语法分析后生产解析数；
3. 接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树；
4. 在转交给对应的模块处理；
5. 如果是select查询还会经由'查询优化器'做大量优化，生成执行计划；
6. 模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限；
7. 有则调用‘表管理模块’，显示查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件；
8. 根据表的meta数据，获取表的存储引擎 等信息，通过接口调用对应的存储引擎处理；
9. 上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中。

MySQL连接数

MySQL数据库默认最大的连接数是100，当并发数过大的时候会出现连接数不够用，是的很多线程在等待其它链接释放，会直击导致数据库链接超时或者响应时间过程，所以需要调整最大连接数。

# 重新设置数据库最大连接数
set global max_connections=1000 

# 查询数据库当前设置的最大连接数
show variables like '%max_connections%'; 
MariaDB [(none)]> show variables like '%max_connections%'; 
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| extra_max_connections | 1     |   # extra_port可以接受的最大连接数
| max_connections       | 151   |   # 最大连接数
+-----------------------+-------+
2 rows in set (0.00 sec)

# extra_port是之前5.6版本开始新增的，指定了可以使用的端口


# 服务器响应的最大连接数
show global status like 'Max_used_connections'; 
MariaDB [(none)]> show global status like 'Max_used_connections'; 
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 4     |
+----------------------+-------+
1 row in set (0.00 sec)

# 服务器线程方面的
show status like 'Threads%';
MariaDB [(none)]> show status like 'Threads%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 0     |   # mysql管理的线程池中还有多少可以被复用的资源
| Threads_connected | 3     |   # 打开的连接数
| Threads_created   | 226   |   # 表示创建过的线程数
| Threads_running   | 1     |   # 激活的连接数，这个数值一般远低于connected数值，
                                # 准确的来说，Threads_running是代表当前并发数
+-------------------+-------+
4 rows in set (0.00 sec)

MySQL缓存

数据库属于IO密集型的应用程序，其主要职责就是数据的管理及存储工作。从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个io实在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是io，尽可能讲磁盘io转化成内存io

缓存分为两个维度，查询缓存Query cache和存储引擎InnoDB_Buffer_Pool

• 查询缓存Query cache

查询缓存会缓存完整的SELECT查询结果，当查询命中缓存时MySQL会将结果立刻返回，直接跳过了解析、优化和执行阶段。

当然，Query Cache 也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query Cache 中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache 可能会得不偿失。

因此，应用程序不需要关心MySQL是通过缓存查询出的结果还是实际执行过SQL语句返回的结果，因为这两种结果是完全相同的。

从前面的数据库执行过程图中可以看到，执行一条SQL查询语句会先查询该语句是否存在于缓存中，需要注意的是当语句中的字符大小写或注释只要有一点点的不同，查询缓存就会被认为是不同的查询，导致无法命中查询缓存。另外，对于不确定的函数，如：now()、current_date()等这种查询都不会被缓存。

既然查询缓存的有可以改善性能的优点，自然也有自己的缺点，主要体现在当开启了查询缓存时对于读写操作都增加了额外的开销。相对于读，再查询开始前需要先检查缓存，而对于写，则是当写入数据后需要更新缓存。

• Query cache的参数
  查询缓存参数，在MySQL配置文件中添加，Linux下为my.cnf，Windows下为my.ini：

# 1.是否开启查询缓存，具体选项是off，on
query_cache_type = on

# 2.分配给查询缓存的总内存，一般建议不超过256M
query_cache_size = 200M 

# 3.这个选项限制了MySQL存储的最大结果。如果查询的结果比这个大，那么就不会被缓存。
query_cache_limit = 1M

# 查询qcache状态：

MariaDB [(none)]> show variables like '%query_cache%';
+------------------------------+---------+
| Variable_name                | Value   |
+------------------------------+---------+
| have_query_cache             | YES     |  #该MySQL 是否支持Query Cache
| query_cache_limit            | 1048576 |  #缓存块大小，超过该大小不会被缓存 
| query_cache_min_res_unit     | 4096    |  #每个qcache最小的缓存空间大小 
| query_cache_size             | 1048576 |  #分配给查询缓存的总内存 
| query_cache_strip_comments   | OFF     |  #用于控制QC中是否去掉SQL语句的注释部分。
| query_cache_type             | OFF     |  #是否开启
| query_cache_wlock_invalidate | OFF     |  #控制当有锁加在表上的时候，是否先让该表相关的缓存失效
+------------------------------+---------+
7 rows in set (0.00 sec)

修改完配置后，让我们再来监控Qcache的使用情况

# 查询qcache当前使用情况：
SHOW STATUS LIKE 'Qcache%';

MariaDB [(none)]> show status like 'Qcache%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Qcache_free_blocks      | 1       | # 表示查询缓存中处以重现状态的内存块数（碎片数量）。如果
                                      # Qcache_free_blocks 的值较大，则意味着查询缓存中碎片比较多
                                      # 表明查询结果集较小，此时可以减小query_cache_min_res_unit
                                      # 使用flush query cache 会对缓存中的若干个碎片进行整理，从
                                      # 而得到一个比较大的空闲块。
| Qcache_free_memory      | 1031336 | # Query Cache 中目前剩余的内存大小 
| Qcache_hits             | 0       | # 缓存命中次数 
| Qcache_inserts          | 0       | # 多少次未命中然后插入 
| Qcache_lowmem_prunes    | 0       | # 因为查询缓存已满而溢出，导致MySQL删除的查询结果个数。
                                      # 如果该值比较大，则表明查询缓存过小。
| Qcache_not_cached       | 0       | # 没有进入查询缓存的select个数
| Qcache_queries_in_cache | 0       | # 查询缓存中缓存中有多少条select语句的结果集
| Qcache_total_blocks     | 1       | # 查询缓存的总个数
+-------------------------+---------+
8 rows in set (0.00 sec)

Query Cache 命中率= Qcache_hits / ( Qcache_hits + Qcache_inserts )； 

未完待续