handler handlemessage_handlersocket_乐视2crashhandler停止(3)

即使所有的并发问题都得到处理，估计也很难做到300,000 qps。

或许你听说过HANDLER statement的性能也不错。

可是HANDLER statement需要query parsing，需要open/close table。

不会有太大的帮助。

在完全内存操作的情况下，CPU的效率非常重要

如果只有一小部分数据能够进入内存，那么SQL语句的解析带来的额外负担已经不算什么了。

因为磁盘的IO操作会消耗更长的时间。

在我们的mysql服务器中，内存是大大的，几乎所有的数据都可以放进内存。

SQL层就变成了额外负担,占用了大量的cpu资源。

上的应用中，我们要进行大量的PK查询。即使70-80%的查询都是在同一张表上进行的， mysql还是每次都要parse/open/lock/unlock/close，看起来就感觉效率低下。

We needed to execute lots of primary key lookups(i.e. SELECT x FROM t WHERE id=?) or limited range scans. Even though 70-80% of queries were PK lookups from the same table (difference was just values in WHERE), every time MySQL had to parse/open/lock/unlock/close, which seemed not efficient for us.

花荣注：难道说mysql中的table_open_cache不是用来减少table open的次数的么。。

NDBAPI

有没有办法在sql层进行优化呢？

如果你使用mysql cluster, NDBAPI会是最佳解决方案。

It’s recommended using NDBAPI for frequent access patterns,

and using SQL + MySQL + NDB for ad-hoc or infrequent query patterns.

这就是我们想要的：

1 faster access API.

2 sql语句仍然要可用,以处理一些特定的或者复杂的查询。

但是，把innodb转化成ndb可不是一件轻松的事情。

HandlerSocket Plugin

最好的办法是在mysql内部实现一个NoSQL的网络服务。daemon plugin。

它在某个端口，接受NoSQL 协议/API的数据包，使用Mysql internal storage engine API直接在innodb数据表上进行操作，并且返回相应的数据。

关于mysql internal storage engine API可以看这个文档：

这个概念首先被Cybozu Labs 的Kazuho Oku 提出，然后他写了一个MyCached UDF，用的是memcached的协议。

随后，Akira Higuchi 写了另外一个plugin: HandlerSocket。

从图中可以看到，客户端既可以使用普通的mysql api来操作mysql(3306端口)，

也可以使用HandlerSocket API对进行PK查询，以及INSERT/UPDATE/DELETE操作(9998与9999端口)。

在使用HandlerSocket操作的时候，省去了SQL parsing, Opening table, Making Query Plans, Closing table等步骤。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-27116-3.html