Mysql配置估算-姜博文

影响QPS的因素有很多，常见的有：
key Buer命中率
Innodb Buer命中率
Query Cache命中率
I/O吞度量 … … 等等一系列缓存的命中情况与参数配置，以下计算方法皆基于Mysql服务器与程序经过持续优化后的情况讨论。

在4核16G配置下

QPS根据业务情况进行计算：
在对数据库延时要求较为严格的系统场景下，我们假设单个Query的时间为10ms 对于4核CPU，在极限情况下可以并发处理4个线程(此处不考虑线程间的上下文切换)，那么此时Mysql服务器可以支 撑400QPS：

QPS并没有一个准确的计算标准，只能根据业务场景进行计算。 例如在INSERT操作极为频繁的业务场景下，Cache命中率就会极为低下，但是查询操作却极少。此时QPS受到Cache 命中率的影响较小，QPS则会根据index的设计而进行伸缩。但是在UPDATE与SELECT操作都较为频繁的业务场景 下，QPS就会相比极限状况小上很多。因为此时index的更新频繁，I/O占用较大，且Cache命中率低下。 对于Mysql的性能查询

所以，我们对于当前服务器的QPS应当具体优化，以达到无限趋近与极限状况下的QPS预期。

1. 计算当前QPS 查询所有Query
   查询启动时间
   计算公式为：
   1000ms/10ms*4=400QPS
   show global status like ‘Questions’;
   show global status like ‘uptime’;
   /
   那么此时的QPS为0.1 2. 计算常用Cache命中率 2.1 InnoDB Buer
   计算公式为：
   那么当前的InnoDB Buer命中率则为99.98%(这也太高了。。。) 如果在SELECT操作极多的情况下，该值低于80%，就应该考虑调整InnoDB Buer Pool的容量，以支持更多的 缓存加入。 或者查询
   该值不为0，则表示Innodb引擎在写入Buer Pool时产生了等待，也需要对InnoDB Buer Pool的容量进行优 化。 2.2 Table Cache 该值的命中率不用太过关心，直接给出计算方法：
   2.3 Query Cache 对于数据会被重复查询的业务场景，且数据不会被频繁修改！此时可以开启Query Cache。
   QPS = Questions / uptime
   show status like ‘innodb_buffer_pool_read%’;
   InnoDB_Buffer_Hit = (1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100%
   show status like ‘innodb_log_waits’;
   table_open_cache = max_connections * SQL中最大的多表查询语句中的表数量
   show status like ‘Qcache%’;
   /
   计算公式为：

那么当前的Query Cache命中率为97.16% 配置计算
对于配置的计算方式，内存体积皆为经验之谈，具体计算方式应根据业务场景具体计算：内存通常为CPU核数的4 倍。而CPU的核心数，根据业务场景，判断单个Query所能接受的时长Query_Time，与前端业务处理侧的单日的PV 数PV。

计算公式为：
该公式基于 每天80%的访问集中在20%的时间里 这一理论，720该值可以随意修改。

Query_Cache_Hit = (Qcache_hits / (Qcache_hits + Qcache_inserts)) * 100%
业务忙时所需QPS峰值 = (PV * 80%) / 720 CPU核心数 = 业务忙时所需QPS峰值 / Query_Time