MYSQL Handler Socket插件（二）性能测试

关注

转载最新推荐文章于 2026-07-31 12:38:58 发布 1.8k 阅读 AI 写同款· GEO 优化 ›

WebSocket之仿QQWeb即时聊天系统：从零到一的Node.js实战本文详细介绍了如何使用Node.js和WebSocket技术从零开发一个仿QQ的Web即时聊天系统。内容涵盖技术选型、核心功能实现、性能优化及安全防护等关键环节，特别解析了WebSocket低延迟通信、消息存储设计等核心技术点，为开发者提供完整的实战指南。阅读详情

HandlerSocket Oprofile测试报告

(MySQL通过SQL执行K/V查询的Oprofile信息)

MySQL执行SQL语句，首先要经过SQL解析阶段，调用MYSQLparse() 和MYSQLlex() 进行语法和词法解析；然后进入查询优化阶段，调用make_join_statistics() 和JOIN::optimize() 获得统计信息和生成执行计划，可以清洗第发现，主要耗资源的是SQL解析和优化层，而不是InnoDB存储层，row_search_for_mysql只消耗了很少的时间。

因此我们对比Memcached/NoSQL，知道MySQL除了数据操作，还要很多额外的步骤需要完成：
1 Parsing SQL statements【解析SQL】
2 Opening, locking tables【打开并锁定表】
3 Making SQL execution plans SQL【解析SQL并生成执行计划】
4 Unlocking, closing tables【解锁并关闭表】
另外，MySQL 还必须要做大量的并发控制，比如在发送/接收网络数据包的时候，fcntl() 就要被调用很多次；Global mutexes比如LOCK_open，LOCK_thread_count也被频繁地取得/释放。所以在Oprofile的输出中，排在第二位的是my_pthread_fastmutex_lock()。并且Mutex的竞争带来的上下文切换，导致%system占用CPU使用比例相当高（>20%）。

其实， MySQL 开发团队和外围的开发团体早已意识到大量并发控制对性能的影响，MySQL 5.5中已经解决了一些问题，Percona也对Mutex做了一些拆分处理，未来的MySQL版本中，也应该会越来越好。

在完全内存操作的情况时，CPU的效率非常重要。如果只有一小部分数据进入内存，那么SQL语句带来的消耗可以忽略不计。很简单，因为机械磁盘IO操作的时间消耗远比CPU解析SQL语句的时间消耗多，这种情况下，就不需要过分考虑SQL语句所带来的消耗。但是对于SSD盘，尤其是PCI-E SSD盘，响应时间在微秒级（Fusion I/O为30us左右），就必须考虑SQL带来的消耗了。
在大多数的MySQL 服务器中，大部分的热点数据都缓存在内存中，因而访问变得只受CPU的限制。Profiling 的结果就类似上所述的情况：SQL 层消耗了大量的资源。假设需要做大量的PK查询（例如：SELECT x FROM t WHERE id=?）或者是做LIMIT的范围查询，即使有70-80%都是在同一张表中做PK查询（仅仅只是查询条件中给定的值不同，即value不同而已）， MySQL 还是每次需要去做 parse/open/lock/unlock/close，这对我们来说是非常影响效率的事情。