对于每秒读MYSQL好几次，有没有好点的思路

每秒几次压根就不是问题啊。MYSQL性能都能承受每秒几十万次并发。

要是这个都有问题只能说是你数据库所在的服务器性能问题。

前提硬件配置跟上，硬件不行再怎么优化都是扯蛋。

你这种真不算啥，还有个地方是查询逻辑是不是有问题。

数据库另外一个推荐是 redis

随着Web应用变得越来越复杂，单纯的MySQL + Memcached似乎已满足不了数据存储的需求，一些企业纷纷转向NoSQL方案，比如MongoDB、CouchDB、 TokyoCabinet/Tyrant、Cassandra等。在他们看来，如果数据访问模式不是很复杂，用不上SQL数据库。然而，DeNA公司截然相反，他们选择了 "only MySQL" 的方案，且获得了远远超越NoSQL的性能。

该公司仍在使用MySQL + Memcached，Memcached主要用于前端Cache，比如预处理的HTML、计数和摘要信息等，但数据行并不放在Cache里，而是直接从数据库查，因为普通的服务器就可以获得75万次每秒的查询，当前又有哪种NoSQL可以做到呢？

可以使用sysbench、super-smack、mysqlslap等工具测试MySQL性能，比如

[matsunobu@host ~]$ mysqlslap --query="select user_name,..

from test.user where user_id=1" \

--number-of-queries=10000000 --concurrency=30 --host=xxx -uroot

然后使用如下命令得到每秒读取的行数，

[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 |

...

可以使用vmstat和Oprofile等工具诊断系统瓶颈。

MySQL Cluster因为性能问题一直受人批判，为改善这种情况引入了NDBAPI，使得性能提升了N倍。但对于非集群情况怎么优化呢？通过MySQL瓶颈分 析，发现大部分时间花费在SQL解析和表 *** 作上，如果绕过这层 *** 作直接存取存储引擎，可大大提升性能，MySQL的插件HandlerSocket正是由 此获得了每秒75万次查询 *** 作的性能，这个评测数据无疑会颠覆整个NoSQL世界。另外，HandlerSocket支持批量读取和写 *** 作，这进一步提升 了它的性能。

如何做mysql每秒可以处理多少次读写 *** 作的测试

写 *** 作多的话，首先存储引擎得用innodb,考虑到你没秒23次的写入，那么一天的数据量接近两百万，数据过大，一个月的数据就是很大了，可考虑分表

---