Schema的优化和索引 - 关于存储引擎的简单记录
2009-09-02 00:00:00 来源：WEB开发网这一章的结束，我们来说一下关于设计模型的存储引擎的选择，这些你应该牢记。我们不会全面的介绍存储引擎，目标就是列出一些影响数据模型设计的一些关键性因素。
MyISAM存储引擎
表锁（Table locks）
MyISAM是表一级的锁。小心地是这个不会成为一个瓶颈。
没有自动数据恢复（No automated data recovery）
如果MySQL服务器挂了或者电源关闭。你应该在使用表之前来修复MyISAM表。如果有个大表，这个过程可能会持续几个小时。
不支持事物（No transactions）
MyISAM不支持事物。事实上，MyISAM表不能保证一个单独的语句会执行完成。如果一个错误发生在多个UPDATE之中，一些行被更新而另外的行并不会更新。
只有索引会被缓存（Only indexes are cached in memory）
在MySQL进程内部，关键的缓冲区中，MyISAM只会缓存索引。操作系统缓存了表的数据，因此在MySQL5.0中，要想获取数据，就需要操作系统的调用。这个过程消耗是较大的。
压缩存储（Compact storage）
每一行都是紧挨着的，因此需要的硬盘就会小并且全表扫描就会很快。
Memory存储引擎
表锁（Table locks）
像MyISAM表一样，Memory表支持表锁。这不是个问题，因为语句都是在内存中执行的。非常快。
没有动态的行（No dynamic rows）
Memory表不支持动态（比如，变量的长度）行，因此它们不支持BLOB,TEXT字段。一个VARCHAR(5000)转为CHAR(5000)-如果大部分数据都是小的话，就会浪费大量内存。
Hash索引是默认的索引类型（Hash indexes are the default index type）
不像其他的存储引擎，它的默认索引类型是hash。
没有索引统计（No index statistics）
Memory表不支持索引统计，因此可能对于复杂的查询，执行很不理想。
重启动后内容丢失（Content is lost on restart）
Memory不会持久化任何数据。因此服务器重启后，数据都会丢失，但表还是存在的。
InnoDB存储引擎
事物（Transactional）
InnoDB支持事物，并且支持4个级别的事物隔离级别。
外键（Foreign keys）
MySQL5.0，InnoDB是唯一支持外键的存储引擎。其他存储引擎在CREATE TABLE时可以创建外键，但是不会约束。一些第三方引擎，比如solidDB以及PBXT，在存储引擎级别支持它们。MySQL AB准备在服务器级别支持外键。
行锁（Row-level locks）
锁在行的一级。没有扩大和非阻塞的select-标准的select不会设置任意的锁。这样并发性比较好。
多版本（Multiversioning）
InnoDB使用多版本并发控制，因此默认的你的select会读取健壮的数据。事实上，MVCC架构添加了很多复杂性和可能的意外现象。你应该仔细阅读InnoDB手册。
通过主键来聚簇（Clustering by primary key）
所有的InnoDB表都是通过主键来聚簇的。这个可以用来更高级别的数据模型设计。
所有的索引都包含主键列（All indexes contain the primary key columns）
索引用主键来引用行。如果你的主键很长，那么索引的增长会特别快速。
缓存的优化（Optimized caching）
在缓冲池，InnoDB缓存了数据和内存。它也自动创建Hash索引来加速行的获取。
无压缩的索引（Unpacked indexes）
索引并没有前缀压缩。因此它们要大于MyISAM表的索引。
数据读取缓慢（Slow data load）
MySQL5.0，InnoDB没有优化读取数据的操作。它一次给一行创建了索引。而并不是排序的创建它们。这就导致读取数据很慢。
阻塞的AUTO_INCREMENT（Blocking AUTO_INCREMENT）
在MySQL5.1较早的版本，InnoDB使用表级别的锁来生成AUTO_INCREMENT值。
不会缓存COUNT(*)的值
不像MyISAM表或者Memory表，InnoDB表并不存储表的行数。也就是说没有WHERE条件的COUNT(*)并不会优化，并且需要整个表的扫描。下一章会说优化COUNT()语句。
中查找“Schema的优化和索引 - 关于存储引擎的简单记录”更多相关内容
中查找“Schema的优化和索引 - 关于存储引擎的简单记录”更多相关内容更多精彩
赞助商链接
