五、数据库优化之缓存

（一）Query Cache

1.作用于整个 MySQL ，主要用来缓存 MySQL 中的 ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。

当我们打开了 Query Cache 功能，MySQL在接受到一条select语句的请求后，MySQL 会直接根据HASH算法将select语句以字符串方式进行hash，然后到Query Cache 中直接查找是否已经缓存。

如果已经在缓存中，该select请求就会直接将数据返回。

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

2.Query Cache的使用需要多个参数配合，其中最为关键的是 query_cache_size 和 query_cache_type ，前者设置用于缓存 ResultSet 的内存大小，后者设置在何种场景下使用 Query Cache。

在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query_cache_size 一般 256MB 是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率（Qcache_hits/(Qcache_hits+Qcache_inserts)*100)）来进行调整。

query_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache（使用sql_no_cache）之外的所有的select都使用query cache，只有显示要求才使用query cache（使用sql_cache）。

（二）Binlog Cache

Binlog Cache 用于在打开了二进制日志记录功能的环境，用于短时间内临时缓存binlog数据。

一般来说，如果我们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。

但是如果我们的数据库大事务较多，写入量比较大，可与适当调高binlog_cache_size。

（三）Key Buffer

       key_buffer_size 参数用来设置用于缓存 MyISAM存储引擎中索引文件的内存区域大小。如果我们有足够的内存，这个缓存区域最好是能够存放下我们所有的 MyISAM 引擎表的所有索引，以尽可能提高性能。

（四）innodb_buffer_pool_size

       用来设置用于缓存 InnoDB 索引及数据块的内存区域大小，类似于 MyISAM 存储引擎的 key_buffer_size 参数。

       简单来说，当我们操作一个 InnoDB 表的时候，返回的所有数据或者去数据过程中用到的任何一个索引块，都会在这个内存区域中走一遭。

       所以如果我们有足够的内存，尽可将该参数设置到足够大，将尽可能多的 InnoDB 的索引及数据都放入到该缓存区域中，直至全部。我们可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率，并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。

（五）innodb_log_buffer_size

       这是 InnoDB 存储引擎的事务日志所使用的缓冲区。

       InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innodb Log Buffer 中，当满足一定条件（比如日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。

       可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。

六、数据库优化之存储引擎

（一）Mysiam

1-1特性

1.        1. 不支持事务：MyISAM存储引擎不支持事务，所以对事务有要求的业务场景不能使用
2.        2. 表级锁定：其锁定机制是表级索引，这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能
3.        3. 读写互相阻塞：不仅会在写入的时候阻塞读取，MyISAM还会在读取的时候阻塞写入，但读本身并不会阻塞另外的读
4.        4. 只会缓存索引：MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO，但是这个缓存区只会缓存索引，而不会缓存数据

1-2适用场景

1. 1. 不需要事务支持（不支持）
2. 2. 并发相对较低（锁定机制问题）
3. 3. 数据修改相对较少（阻塞问题）
4. 4. 以读为主
5. 5. 数据一致性要求不是非常高

（二）InnoDB

2-1特性

1. 1.具有较好的事务支持：支持4个事务隔离级别，支持多版本读
2. 2.行级锁定：通过索引实现，全表扫描仍然会是表锁，注意间隙锁的影响
3. 3.读写阻塞与事务隔离级别相关
4. 4.具有非常高效的缓存特性：能缓存索引，也能缓存数据
5. 5.整个表和主键以Cluster方式存储，组成一颗平衡树
6. 6.所有Secondary Index都会保存主键信息

2-2适用场景

1. 1.需要事务支持（具有较好的事务特性）
2. 2.行级锁定对高并发有很好的适应能力，但需要确保查询是通过索引完成
3. 3.数据更新较为频繁的场景
4. 4.数据一致性要求较高
5. 5.硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，尽可能减少磁盘 IO

（三）NDBCluster

3-1特性

1. 1. 分布式：分布式存储引擎，可以由多个NDBCluster存储引擎组成集群分别存放整体数据的一部分
2. 2. 支持事务：和Innodb一样，支持事务
3. 3. 可与mysqld不在一台主机：可以和mysqld分开存在于独立的主机上，然后通过网络和mysqld通信交互
4. 4. 内存需求量巨大：新版本索引以及被索引的数据必须存放在内存中，老版本所有数据和索引必须存在与内存中

3-2适用场景

1. 1. 具有非常高的并发需求
2. 2. 对单个请求的响应并不是非常的critical
3. 3. 查询简单，过滤条件较为固定，每次请求数据量较少，又不希望自己进行水平Sharding

总结：

               如上，技术在于交流流通，/握手

原文作者：高一级花阿梨喜欢吃榴莲

https://blog.csdn.net/weixin_40459875/article/details/80949844