本期，我们讨论MySQL的性能调优和集群方案。

我们常遇到一个问题，增加服务器配置并不能增加数据库性能（吞吐量），因为不根据实际配置修改MySQL配置文件的话，再强的硬件配置也只是浪费。

我们按这样的顺序介绍：​

1. 明确性能指标 

2. 服务器硬件选择 

3. 单个mysql服务性能调优 

4. 集群方案 

明确性能指标

在调优之前需要先明确性能指标，根据往期《性能指标》，整体系统的性能指标是并发量、吞吐量、错误率、响应时间。 

在调试单个服务时，根据往期《调优基本思路》的结论，只需要明确吞吐量即可。如果整个系统的吞吐量指标为1000rps，则MySQL读吞吐量最好为2000rps，写操作吞吐量1000rps。

这里需要说明的是，MySQL的吞吐量与数据量是相关联的，所以目标吞吐量也是需要以一定数据量为前提的，我们一般以单表10万行或100万行作为基准，当然，具体数据量基准最好是根据具体业务作调整。

另外，一般MySQL的吞吐量极限在几万rps左右，且随着数据量增多，吞吐量会越来越低，如果需要更高的吞吐量，则需要额外设计缓存机制等编程机制规避性能局限。

而错误率最好为0%，响应时间不需要特别关注 ，但如果出现一些响应时间特别长的数据操作还是要优化的。

​最大并发量是设置的，设置的值可以低于整体系统的最大并发值。

服务器硬件选择

Mysql的硬件选择：CPU核数、内存大小、磁盘性能都是重点选择，当然带宽也是不容忽视的。

对于具体哪个硬件配置存在性能瓶颈的判断，可以参考往期《内核参数调优》。

单个MySQL服务调优

接下来是对单个MySQL服务调优，在这之前，需要先调优服务器内核参数，调优方法可以参考往期《内核参数调优》。

MySQL工作原理以及调优设置可以参考往期《数据库工作原理、调优》。

经过调优后，一台4核CPU、16G内存、7200转/s机械硬盘上运行MySQL8，单表10万行数据的前提下。

用sysbench工具模拟1000并发请求，查询的吞吐量达到30000rps以上（查询性能更依赖CPU、内存）。写操作的吞吐量达到8000rps以上（写操作性能更依赖磁盘性能）。

集群方案-管理中间件​

主从复制不能作为高可用的方案 ，如果有高可用或者读写分离的需求，我们更推荐使用MySQL的管理中间件，如mycat、mysql router、mysql Fabric等，这也是第二种方案。

管理中间件可以作为统一入口，自动负载请求到主或从服务器，主服务器宕机后，自动升级一台从服务器作为主服务器。

集群方案-分片存储

最后一种方案是分片存储，分片存储是将数据按一定的规则存储在多个服务器中。

分片存储的好处是数据容量的扩展是相对容易的，但也会让系统结构更为复杂，增加运维成本。建议等数据量接近1TB或单表接近1000万行再考虑此模式。

分片存储的实现方式有很多种，可以使用myCat等中间件作为分片存储的手段。

也可以使用官方的mysql cluster 或者其他集群方案（PXC等）。这些集群方案提供更完备功能的同时，结构也更加复杂。

总结

除了以上提到的点，在数据库使用上也需要注意，关于数据库设计及使用上的一些问题，如分库等，可以参考往期《数据库设计》的内容。

介绍完了redis、mysql后，你可能会发现，数据库类软件的集群模式基本是雷同的，如主从模式、能自动升级主机的主从模式 以及分片存储集群等。