excle 里面的if函数如何嵌套？

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 最近还是推出了几项重大更新）。