影响MySQL性能的原因总结一下，主要如下：
-
服务器硬件；
- CPU：
- 64位的CPU一定要工作在64位的系统下；
- 对于并发比较高的场景，CPU的数量比频率更重要；
- 对于密集型场景和负责SQL，则CPU频率越高越好
- 内存：
- 选择主板所能使用的最高频率的内存；
- 内存的大小对于性能很重要，所以尽可能的大；
- CPU：
网卡流量；
磁盘IO；
SQL查询速度；
Mysql 的查询过程
- 先查询缓存，检查query语句是否完全匹配，接着在检查是否具有权限，都成功则直接取数据返回；
- 上一步有失败则转交给‘命令解析器’，经过词法分析，语法分析后生产解析数；
- 接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树；
- 在转交给对应的模块处理；
- 如果是select查询还会经由'查询优化器'做大量优化，生成执行计划；
- 模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限；
- 有则调用‘表管理模块’，显示查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件；
- 根据表的meta数据，获取表的存储引擎 等信息，通过接口调用对应的存储引擎处理；
- 上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中。
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 )；
未完待续
