学软件技术,读第一手资料,去官方网站:MySQL 5.7参考手册
也可以看看比较经典的书籍,如《高性能MySQL》等
首先记住一句话:尽管MySQL中有很多存储引擎,但是99%的情况都会选择事务性存储引擎InnoDB,而不会选择既不支持事务又不支持崩溃后的安全恢复的MyISAM。
InnoDB是MySQL的默认存储引擎,这个存储引擎是值得花时间深入研究的。InnoDB的数据存储在表空间(tablespace) 中,表空间是由InnoDB管理的一个黑盒子,由一系列的数据文件组成。在MySQL 4.1 以后的版本中,InnoDB 可以将每个表的数据和索引存放在单独的文件中。InnoDB也可以使用裸设备作为表空间的存储介质,但现代的文件系统使得裸设备不再是必要的选择。
InnoDB采用MVCC来支持高并发,并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ (可重复读),并且通过间隙锁(next-key locking)策略防止幻读的出现。间隙锁使得InnoDB不仅仅锁定查询涉及的行,还会对索引中的间隙进行锁定,以防止幻影行的插入。
InnoDB表是基于聚簇索引建立的,我们会在后面的章节详细讨论聚簇索引。InnoDB 的索引结构和MySQL的其他存储引擎有很大的不同,聚簇索引对主键查询有很高的性能。不过它的二级索引(secondary index,非主键索引)中必须包含主键列,所以如果主键列很大的话,其他的所有索引都会很大。因此,若表.上的索引较多的话,主键应当尽可能的小。InnoDB 的存储格式是平台独立的,也就是说可以将数据和索引文件从Intel平台复制到PowerPC或者Sun SPARC平台。InnoDB内部做了很多优化,包括从磁盘读取数据时采用的可预测性预读,能够自动在内存中创建hash索引以加速读操作的自适应哈希索引(adaptivehashindex),以及能够加速插人操作的插入缓冲区(insert buffer)等。
InnoDB的行为是非常复杂的,不容易理解。如果使用了InnoDB 引擎,笔者强烈建议阅读官方手册中的“InnoDB 事务模型和锁”一节。详细请点击 The InnoDB Storage Engine? 如果应用程序基于InnoDB构建,则事先了解一下InnoDB的MVCC架构带来的一些微妙和细节之处是非常有必要的。存储引擎要为所有用户甚至包括修改数据的用户维持一致性的视图,是非常复杂的工作。作为事务型的存储引擎,InnoDB通过一些机制和工具支持真正的热备份,Oracle提供的MySQL Enterprise Backup、 Percona 提供的开源的XtraBackup都可以做到这一点。MySQL的其他存储引擎不支持热备份,要获取一致性视图需要停止对所有表的写人,而在读写混合场景中,停止写入可能也意味着停止读取。
|