一旦步骤2中的操作完成，就确保了事务的提交，即使在执行步骤3时数据库发送了宕机。此外需要注意的是，每个步骤都需要进行一次fsync操作才能保证上下两层数据的一致性。步骤2的fsync参数由sync_binlog控制，步骤2的fsync由参数innodb_flush_log_at_trx_commit控制。 最后这句话有笔误吧。

mysql> explain select * from products where actor='Jerry' and title like '%Tech%'; 这个语句无法使用覆盖索引有两个原因： 1. 没有任何的列能够覆盖这个查询，因为查询中选择了所有列，而没有任何索引能覆盖所有的列。但是MySQL利用ICP机制还是有捷径可以利用，WHERE条件中的列是有索引的可以覆盖的，因此MySQL可以使用该索引找到对应的actor并检查title是否匹配，过滤之后再去InnoDB层读取需要的数据行，这就是MySQL 5.6的ICP（index condition pushdown）机制。 2. MySQL不能再索引中执行LIKE %string%操作，这是底层引擎的API限制。但是可以执行LIKE string%，是可以根据左前缀匹配利用索引，因为该操作可以转换为简单的比较操作。 能解释下，如果是5.6里用到了ICP,那这个ICP和延迟关联的做法纠结会选哪个呢，这种延迟关联会比ICP快吗

我看错了，是1/16

我看错了。是1/16

因此，InnoDB存储引擎内部对更新Cardinality信息的策略为： 表中1/16的数据已发送过变化。 这句错了，是1/6不是1/16，希望改正下