mysql在百度之类的大公司中性能

看对数据库的需求的，memsql 确实快，但是加载数据结构慢。memsql 可以兼容MYSQL 。目前国内部分网站已经着手在测试环境使用memsql ，再是使用的时候是没有什么区别的。

MemSQL 提供开发版和试用版，开发版可免费使用，数量限制10G，试用版无限制但只能使用30天。 测试都是开发版，所以无法给出准确答复，不过肯定是有提升的。

他们唯一的区别在于，如果你同时都安装了。连接的时候区别端口就可以了

你可以使用 mysql 的命令行或者是 mysql 的客户端工具连接到 MemSQL，跟连接到 MySQL 的方法一样，例如：

$ mysql -u root -h 127.0.0.1 -P 3307 --prompt="memsql>"

你也可以使用一些图形化的数据库管理工具来连接。

使用 MemSQL 跟使用 MySQL 没有区别：

不过对于吧数据存放在内存里的，我是不建议用的，可以当作暂时但高反问率的数据流存储空间使用。我感觉，和MySQL的memery引擎是类似的。

MemSQL宣称支持ACID，其中耐久性是最重要的一环。MySQL的InnoDB默认是很耐用的，如果事务返回为“同意”，就会在崩溃后刻到磁盘上。MemSQL默认也是很“耐久”的，它也会有一个事务日志，而这并不意味着跟磁盘有关。

MemSQL也有事务缓冲设置，默认“完全耐久性模式”会不同时地返回“同意”直到128M缓冲区充满。本质上这跟innodb_flush_log_at_trx_commit=2很相似，在我看来不会很持久。

如果MemSQL激活了完全的耐久性会发生什么呢？结局肯定是悲剧。每次提交都得等后台线程才能写事务日志。多久后台线程才能醒一次？50毫秒一次。MemSQL其实是玩的是计时戏法，每50毫秒冲一次，然后说后台线程一直没醒。

吐槽点一：MemSQL每秒持久事务比InnoDB慢500倍

这一点很容易证明：在磁盘阵列控制器的后写式缓存模式下，InnoDB能够轻易的维持单线程每秒10K的事务，在fsyncs空隙不会停50毫秒。有一些提交分组，两个线程有40tps，十个线程有200tps，但当我选择自己的基准时，MemSQL单线程持久事务率会变得更慢。

既然我们已经确立了MySQL的领先优势，让我们一起来看读写的表现。我敢肯定这方面MemSQL的表现会大亮。MemSQL扫描表的执行速度还是不错的，每秒扫描8M行，这对单线程来说是很了不起的成就。

说实话，我不想花时间用基准问题测试内存数据库所擅长的。我决定测试我最爱的查询：

SELECT * FROM table ORDER BY id DESC LIMIT 5

网上到处是这个查询，MySQL 通过指向索引位置的游标，然后按照指标顺序逐步游动。而MemSQL实际上必须穿越整个目录，分类提供响应。即使是“SELECT MAX(id)”也需要穿越整个目录。

吐槽点二：MemSQL在做一些简单的读写查询时，比MySQL慢上千倍，也许是慢百万倍

我们假设MemSQL在一些普通运算有O(N) performance，因此我们只需找到那个足够大的N。我不知道我们应该如何责备MemSQL的研发人员和被他们误导的那些记者朋友。如果我们回到ACID，A代表原子性，只在语句级实现，BEGIN/COMMIT被无视了。隔离性是提交读。持久性是有缺陷的，我不关心字母C所代表的。我必须承认，MemSQL常见问题中说，MemSQL支持完整ACID事务，当然了，说是这么说。

MemSQL每秒80000次查询没什么值得炫耀的，因为现在MySQL有了HandlerSocket，计算能力接近每秒百万次。当然了，他们也有自己擅长的事情，目前是最快的 MySQL 协议，当然也没超出MySQL Cluster多少。NDB也有很不错的表现。我确信，我上面的两则声明会被一些技术工作所完善。写入性能需要适当的实时与分组提交同步（虽然二进制日志所涉及的工作很复杂，MySQL 最近还是推出了几项重大更新）。

---