QPS，全称是Query Per Second，即每秒查询次数。它是一种衡量系统处理能力的重要指标。"每秒1万"的QPS对于一般的个人网站或者中小型网站来说，是相当高的。但是对于大型网站、互联网公司或高并发系统来说，可能就略显不足。在大流量的互联网公司，其核心业务系统一般要求能够处理每秒数十万甚至上百万的QPS。所以说一个系统的QPS是否高，需要根据具体的业务场景和需求来判断。

首先就互联网公司来说，如果按照1W/S来计算，我们假如一天有10个小时是流量高峰期（这是往高了去估，正常来说有8个小时的话这个公司业务都很火了）10*60*60*1w/s=24000w个请求，我们按照一个请求存储(写）一条mysql数据，也就是24000w条数据，假设我们的表结构如下

CREATE TABLE `task_log` (`id` bigint(20) NOT NULL AUTO_INCREMENT,`task_id` int(11) NOT NULL DEFAULT '0',`name` varchar(32) NOT NULL,`spec` varchar(64) NOT NULL,`protocol` tinyint(4) NOT NULL,`command` varchar(256) NOT NULL,`timeout` mediumint(9) NOT NULL DEFAULT '0',`retry_times` tinyint(4) NOT NULL DEFAULT '0',`hostname` varchar(128) NOT NULL DEFAULT '',`start_time` datetime DEFAULT NULL,`end_time` datetime DEFAULT NULL,`status` tinyint(4) NOT NULL DEFAULT '1',`result` mediumtext NOT NULL,PRIMARY KEY (`id`),KEY `IDX_task_log_protocol` (`protocol`),KEY `IDX_task_log_status` (`status`),KEY `IDX_task_log_task_id` (`task_id`)

各数据类型所占内存大小：

• bigint: 8字节

• int: 4字节

• tinyint: 1字节

• varchar: 1字节/字符（这里仅考虑英文字符，非英文字符存储占用根据字符集会有不同）

• mediumtext: 最大16MB，但实际占用大小取决于实际存储的数据长度

• datetime: 8字节

根据表结构，每一行数据的大小大概如下：

• id: 8字节

• task_id: 4字节

• name: 32字节

• spec: 64字节

• protocol: 1字节

• command: 256字节

• timeout: 3字节（mediumint占3字节）

• retry_times: 1字节

• hostname: 128字节

• start_time: 8字节

• end_time: 8字节

• status: 1字节

• result: 取决于实际存储的数据长度，最长约16MB

所以，除了result字段之外，其余字段固定长度总计大约514字节，result字段的长度会根据实际存储的数据大小而变。因此，如果我们不考虑result字段，那么每行数据大约占用514字节。如果考虑result字段，那么每行数据的大小就需要根据实际插入的数据来进行计算了。那我们就按照514字节来计算，那么我们可以得出一共需要使用的存储大小为:

24000w行 * 514字节/行 = 1233600000000 字节 = 1233600 MB = 1205.078125 GB = 1.1775TB

所以，总共约1.18TB。

以上可以得出1W/S的QPS对于一般企业来说是非常巨大的量，一天的存储大小可以到达1TB，我们这就可以想象对于像腾讯、字节这种超大型互联网企业来说，他们的存储成本就是一个很大的开支。这也是为什么他们那么注重基础，对于这种企业，在设计数据库之初，表结构设计就需要考虑存储成本。

当然对于这种类似的企业，他们还有很多优化手段，像普通的Mysql其实是不能满足的，所以有的时候需要借助于其他大数据存储引擎来进行海量数据的存储。

今天我只从存储成本来进行解释QPS 1W/S，实际支持1W/S及以上的场景还需要其他的配合，如CPU，缓存、算法（比如一次请求的耗时）、负载均衡等多项技术来进行优化。如果级别到了百万QPS，那这个应用肯定是国民级别的，如熔断、降级、限流、稳定性、SLA、容灾、异地多活也全部都要考虑进去了。