MYSQL性能优化之Mysql体系结构，存储引擎

Oracle： 数据文件包括：控制文件、数据文件、重做日志文件、参数文件、归档文件、密码文件。这是根据文件功能行进行划分，并且所有文件都是二进制编码后的文件，对数据库算法效率有极大的提高。由于Oracle文件管理的统一性，就可以对SQL执行过程中的解析和优化，指定统一的标准：
RBO（基于规则的优化器）、CBO（基于成本的优化器）
通过优化器的选择，以及无敌的HINT规则，给与了SQL优化极大的自由，对CPU、内存、IO资源进行方方面面的优化。
MySQL：最大的一个特色，就是自由选择存储引擎。每个表都是一个文件，都可以选择合适的存储引擎。常见的引擎有 InnoDB、 MyISAM、 NDBCluster等。但由于这种开放插件式的存储引擎，比如要求数据库与引擎之间的松耦合关系。从而导致文件的一致性大大降低。在SQL执行优化方面，也就有着一些不可避免的瓶颈。在多表关联、子查询优化、统计函数等方面是软肋，而且只支持极简单的HINT。
SQL Server ：数据架构基本是纵向划分，分为：Protocol Layer（协议层）， Relational Engine（关系引擎）， Storage Engine（存储引擎）， SQLOS。SQL执行过程就是逐层解析的过程，其中Relational Engine中的优化器，是基于成本的（CBO），其工作过程跟Oracle是非常相似的。在成本之上也是支持很丰富的HINT，包括：连接提示、查询提示、表提示。

插件式的意思是，你可以随时改变你的表所使用的存储引擎，比如你建表的时候用的innodb，用了一段时间，用得不爽，你可以随时改存储引擎，engine=xx，改为别的存储引擎，这个就是插件式，随时可以更换存储引擎，随时插拔

存储引擎之MyISAM

frm不是特有的，mysql任何存储引擎都有，用于记录表的结构的。MYD存储数据信息，MYI存储索引信息

MyISAM使用表级锁，所以对表中数据修改时需要对整个表进行加锁。而在对表中数据读取时，也需要对整表加共享锁。可以看出，读取和写入是互斥的，并发性不是太好。如果是只读的操作，就并发性来讲，还是可以接受的，因为共享锁并不会阻塞共享锁。
对表进行修复可能会造成数据丢失。


除了使用repair table myIsam来修复，还可以使用这个工具myisamchk –help(修复时需要将mysql服务停止，要不表就糟了，糟了，糟了)

全文索引，还支持CHAR、VARCHAR、BINARY、VARBINARY、BLOB和TEXT数据列的前缀（前500个字符）索引。

不好意思啊，文件太小啦。只是掩饰啊；
对于已经压缩的表，是不能进行写操作的。只能进行读操作

<