FROM: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server
由于 MySQL 的局限性，很多站点都采用了 MySQL+Memcached 的架构。另外一些站点放弃 MySQL 而采用 NoSQL，比如 TokyoCabinet/Tyrant 等。不可否认，在做一些简单查询 (尤其 PK 查询) 的时候，NoSQL 比 MySQL 要快很多很多。而且网站上的绝大多数查询都是这样的简单查询。
像其他大规模的公司一样，DeNA 也面临过类似的问题。但最后我们采用的是一完全不同的方法, 仅使用了 MySQL。我们仍然使用 Memcached 做前端缓存(例如，预处理 HTML， 数量/摘要 信息)，但在后端，既没有使用 Memcached 缓存任何记录，也没有使用 NoSQL，这是为什么呢？因为与其他的 NoSQL 产品相比，我们的 MySQL 能得到更好的性能。 在我们的基准测试中，一普通的 MySQL/InnoDB 5.1 服务器达到了 750,000+ QPS，生产环境中的性能当然更不列外。或许，你们很难相信这个数字，但这是事实。我将在以下分享我们的经验。
(作者经历)2010-08，我离开了 Oracle, 现在任职于日本最大社交游戏平台供应商之一的 DeNA。
在每秒中，需要做多少次的 PK 查询了？在 DeNA 公司的应用中，经常要进行 PK 查询。比如根据 user id 取出 userinfo，根据 diary id 取出日志内容， 对于这样的需求，不用说，Memcached 和 NoSQL 都相当适合。在简单的多线程 “Memcached GET”基准测试中，很可能每秒进行 400,000 次 get 操作,即使 Memcached client 在不同的服务器。在一台 Nehalem box 2.5GHz x 8 核 CPU, Broadcom 四端口千兆网卡的服务器上，最新的 libMemcached 和 Memcached 每秒可达到 420,000 次 get 操作。
在 MySQL 下， 每秒可作多少次的 PK 查询呢, 我们可用 sysbench, super-smack or mysqlsla 等来进行基准测试
[matsunobu@host ~]$ mysqlslap --query="select user_name,.. from test.user where user_id=1" \\
--number-of-queries=10000000 --concurrency=30 --host=xxx -uroot
通过如下命令，很快就得知 InnoDB 的 QPS 大概为 100,000, 几乎只有 Memcached 的 1/4.
[matsunobu@host ~]$ mysqladmin extended-status -i 1 -r -uroot \\
| grep -e "Com_select"
...
| Com_select | 107069 |
| Com_select | 108873 |
| Com_select | 108921 |
| Com_select | 109511 |
| Com_select | 108084 |
| Com_select | 108483 |
| Com_select | 108115 |
...
看上去， 100, 000+ QPS 也不是太差，但为什么 MySQL 比 Memcached 差这么多呢，MySQL 到底在做什么呢。从 vmstat 的统计信息得知, %user 和 %system 的数据都非常高.
[matsunobu@host ~]$ vmstat 1
r b swpd free buff cache in cs us sy id wa st
23 0 0 963004 224216 29937708 58242 163470 59 28 12 0 0
24 0 0 963312 224216 29937708 57725 164855 59 28 13 0 0
19 0 0 963232 224216 29937708 58127 164196 60 28 12 0 0
16 0 0 963260 224216 29937708 58021 165275 60 28 12 0 0
20 0 0 963308 224216 29937708 57865 165041 60 28 12 0 0
再看 Oprofile 输出，可知 CPU 消耗的出去:
samples % app name symbol name
259130 4.5199 mysqld MYSQLparse(void*)
196841 3.4334 mysqld my_pthread_fastmutex_lock
106439 1.8566 libc-2.5.so _int_malloc
94583 1.6498 bnx2 /bnx
284550 1.4748 ha_innodb_plugin.so.0.0.0 ut_delay
67945 1.1851 mysqld _ZL20make_join_statisticsP4JOINP10TABLE_LISTP4ItemP16st_dynamic_array
63435 1.1065 mysqld JOIN::optimize()
55825 0.9737 vmlinux wakeup_stack_begin
55054 0.9603 mysqld MYSQLlex(void*, void*)
50833 0.8867 libpthread-2.5.so pthread_mutex_trylock
49602 0.8652 ha_innodb_plugin.so.0.0.0 row_search_for_mysql
47518 0.8288 libc-2.5.so memcpy
46957 0.8190 vmlinux .text.elf_core_dump
46499 0.8111 libc-2.5.so malloc
MySQL 的 SQL 解析阶段，有调用 MYSQLparse() 和 MYSQLlex(); 查询优化阶段，调用 make_join_statistics() 和 JOIN::optimize()。很明显，主要耗资源的是SQL 层，而不是 InnoDB 存储层。与 Memcached/NoSQL 比起来，MySQL 还要额外做一些工作：
Parsing SQL statements 解析 SQL.
Opening, locking tables 打开并锁定表.
Making SQL execution plans SQL 执行计划.
Unlocking, closing tables 解锁并关闭表.
另外，MySQL 还必须要做大量的并发控制，比如在发送/接收网络数据包的时候，fcntl() 就要被调用很多次; Global mutexes 比如 LOCK_open，LOCK_thread_count 也被频繁地取得/释放。所以, 在 Oprofile 的输出中，排在第二位的是 my_pthread_fastmutex_lock()。并且 %system 占用的 CPU 相当高(28%)。
其实 MySQL 开发团队和外围的开发团体已意识到大量并发控制对性能的影响，MySQL5.5 中已经解决了一些问题。未来的 MySQL 版本中，应该会越来越好。
还有一个大的问题是，%user 达到了60%。互斥量的争夺导致 %system 上增，而不是 %user，即使 MySQL 内部关于互斥量的的问题都得到修复，还是很难达到我们所期望的 300,000 QPS.也许，会