SELECT c FROM sbtest1WHERE id = ?有了上面的铺垫，接着就可以来实现自己220W QPS的小目标了。
希望各位粉丝看完后点击右下角的“点赞”，以示鼓励。长期坚持原创很不容易，多次想放弃。坚持是一种信仰，专注是一种态度，一路陪伴，一起星辰大海。
上一次，通过参数的调整，我们已经可以让MySQL 8.0.23版本跑出了140万的QPS佳绩。见：QPS从20W到140W，一个参数让MySQL 8.0性能提升7倍
取得这样的成绩还是在一台相对较老的服务器上，CPU配置为：Intel(R) Xeon(R) Platinum 8255C，两个24核CPU，支持超线程技术，总共96个逻辑核。
若使用现在更新架构的CPU和更多的核，相信QPS的性能还能不断提升。
不过即便是在当前逻辑96核的CPU基础上，MySQL 8.0.23依然能轻松跑出140万QPS。
测试过程中MySQL实例差不多占用55个逻辑核，每个逻辑核能跑出2.3W的QPS。
但是，请问在同一物理硬件条件下，MySQL QPS还能进一步大幅提升么？
答案是：可以的！！！
CROSSOVER
该调整的数据库和操作系统参数，基本都已经调整完毕。想要在sysbench的测试中再有大突破，几无可能。
所以，不如我们打碎固有的经验，换个角度思考问题。
在sysbench测试中，其测试的SQL语句如下所示：
SELECT c FROM sbtest1 WHERE id = ?
可以看到测试是通过主键查询，返回列c的结果，列c的长度为120个字节。即通过主键返回一个120字节的值。
嗯，这不就是一个KV查询么？通过一个key返回一个120字节的value。
我们是不是可以把MySQL打造成一个KV数据库呢？减少SQL层，直接通过KV接口读取引擎的数据呢？
答案是：可以的。
敲黑板：MySQL早已就打破了关系型与非关系型的边界。
当前，可以通过MySQL打造下面几种类型的数据库：
- 关系型数据库：通过SQL访问MySQL中的数据；
- KV型数据库：通过Memcached协议访问MySQL中的数据；
- 文档数据库：利用JSON特性，打造文档数据库。
下图显示了MySQL的CrossOver跨界能力：
从上图可以看到，MySQL已经支持通过传统的Memcached协议访问数据库中的表，只需做好表的映射关系即可。例如我们可以将sysbench中的表sbtest1映射为KV访问的表：
220W的小目标
经过完整的测试，可以发现通过Memcached Plugin提供的NoSQL接口访问MySQL，性能比传统SQL方式要快至少65%。
以64线程为基准，MySQL Memcached Plugin在64线程的时候性能可达225W，CPU使用为42个逻辑核，差不多5.3万/Core。对比SQL模式，CPU效能的使用率提升130%+。
总结
不要惊讶，通过MySQL跑出220万+的QPS就是这么简单。如果你的业务是偏KV类型的，且是读多写少的场景，不如直接使用MySQL的KV接口。
这样你不但能利用到MySQL强大的性能，还能依旧使用SQL接口进行复杂数据的访问，同时利用复制或MGR技术进行数据的同步。而这在Memcached中，全部无法做到。
KV只是KV，而SQL不仅仅是SQL。