在文件系统中，MySQL将每个数据库（schema）保存为数据目录下的一个子目录。创建表时，MySQL会在数据库子目录下创建一个和表名相同的.frm文件保存表的定义。例如创建一个名为MyTable的表，MySQL会在MyTable.frm文件中保存该表的定义。因为MySQL使用文件系统的目录和文件来保存数据库和表的定义，大小写敏感性和具体的平台密切相关。在Windows中，大小写是不敏感的；而在类Unix中则是敏感的。不同的存储引擎保存数据和索引的方式是不同的，但表的定义则是在MySQL服务层统一处理的。
可以使用SHOW TABLE STATUS命令显示表的相关信息。
输出结果表明这是一个InnoDB表。输出中还有很多其他信息以及统计信息。下面简单介绍下含义
Name：表名
Engine：存储引擎类型。旧版本中叫Type。
Row_format：行的格式
Rows:表中的数据行数。在InnoDB中该值是估算值
Avg_row_leng：平均每行包含的字节数
Data_length：表数据的大小（单位为字节）
Max_data_length：表数据的最大容量，此值与存储引擎相关
Index_length：索引的大小（单位为字节）
Data_free：已分配但未使用的空间
Auto_increment：下一个AUTO_INCREMENT的值
Create_time：创建时间
Update_time：表数据最后修改时间
Check_time：使用CKECK TABLE命令或myisamchk工具最后一次检查表的时间
Collation：表的默认字符集和字符列排序规则
Checksum：如果启用，保存的是整个表的实时校验和
Create_options：创建表时的其他选项
Comment：该列包含了一些其他的额外信息，InnoDB中保存的是表空间剩余空间信息
一 InnoDB存储引擎
InnoDB是MySQL的默认事物型引擎，也是最重要、使用最广泛的存储引擎。它被设计为用来处理大量的短期事物（short-lived），短期事物大部分情况是正常提交的，很少会被回滚。InnoDB的性能和自动崩溃恢复特性，使得它在非事物型存储的需求中也很流行。除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。如果要学习存储引擎，InnoDB也是一个非常好的学习对象。
1.InnoDB的历史
InnoDB有着复杂的发布历史，了解一下这段历史对于理解InnoDB很有帮助。2008年，发布了所谓的InnoDB plugin，适用于MySQL5.1版本，但这是Oracle穿件的下一代InnoDB引擎，其拥有者是InnoDB而不是MySQL。这基于很多原因。MySQL默认还是选择了集成旧的InnoDB引擎。当然用户可以自行选择使用新的性能更好、扩展性更加的InnoDB plugin来覆盖旧的版本。替代了旧版本的InnoDB。
这个现代的InnoDB版本，也就是MySQL5.1中所谓的InnoDB plugin，支持一些新特性，注入利用培训创建索引（building index by sorting）、删除或增加索引时不需要赋值全表数据、新的支持压缩的存储格式、新的大型列值如BLOB的存储方式，以及文件格式管理等、很多用户在MySQL5.1中没有使用InnoDB plugin，或许是因为没有注意到有这个区别、所以如果你使用的是MySQL5.1，一定要使用InnoDB plugin，它要比旧版本好很多。
InnoDB是一个很重要的存储引擎，很多个人和公司都对其贡献代码，而不仅仅是Oracle公司的开发团队。一些重要贡献者包括Google、Yasufumi Kinoshita、Percona、Facebook等，他们的一些改进被直接一直到官方版本，也有一些由InnoDB团队重新实现。在过去的几年里，InnoDB的改进速度大大加快，主要的改进集中在可测量性、可扩展性、可配置化、性能、各种新特性和对Windows的支持等方面。
为改善InoDB的性能，Oracle投入了大量的资源，并做了很多卓有成效的工作。原有版本超过四核CPU的系统中InnoDB表现不佳，而现在已经可以很好的扩展至24核的系统，甚至在某些场景，32核或者更多的系统中也表现良好。很多改进将在MySQL5.6中引入，当然还有更进一步的改善。
2.InnoDB概览
InnoDB的数据存储在表空间中（tablespace），表空间是由InnoDB管理的一个黑盒子，由一系列的数据文件组成。在MySQL4.1以后的版本中，InnoDB可以将每个表的数据和索引存放在单独的文件中。InnoDB也可以使用裸设备作为表空间的存储介质，但现代的文件系统使得裸设备不在是必要的选择。
InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ（可重复读），并且通过间隙锁（next-key locking）策略防止幻影读的出现。间隙锁使得InnoDB不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，以防止幻影行的插入。
InnoDB表时基于聚簇索引建立的。InnoDB的索引结构和MySQL的其他存储引擎有很大的不同，聚簇索引对主键查询有很高的性能。不过它的二级索引（secondary index，非主键索引）中必须包含主键列，所以如果主键列很大的话，其他的所有索引都会很大。因此，若表上的索引较多的话，主键应该尽可能的小。InnoDB的存储格式是平台独立的，也就是说可以将数据和索引文件从Intel平台赋值到PowerPC或者Sun SPARC平台。
InnoDB的行为是非常负载的，不容易理解。如果使用了InnoDB引擎，清冽建议血毒官方手册中的《InnoDB事物模型和锁》这一章节。如果应用程序基于InnoDB构建，则事先了解一下InnoDB的MVCC架构带来的一些细节。存储引擎要为所有用户甚至包括修改数据的用户维持一致性的视图，是非常复杂的工作。
作为事物型的存储引擎，InnoDB通过一些机制和工具支持真正的热备份，Oracle提供的MySQL Enterprise Backup、Percona提供的开源的XtraBackup都可以做到这一点。MySQL的其他存储引擎不支持热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。
二 MyISAM存储引擎
在MySQL5.1及以前的版本，MyISAM是默认的存储引擎。MyISAM提供了大量的特性，包括全文索引、压缩、空间函数（GIS）等，但MyISAM不支持事物和行级锁，而且有一个缺陷，就是崩溃后无法安全恢复。正是由于MyISAM引擎的缘故，及时MySQL支持事物已经很长时间了，在很多人的概念中MySQL还是非事物型的数据库。尽管MyISAM引擎不支持事物、不支持崩溃后的安全恢复，但它绝不是一无是处的。对于只读的数据，或者表比较小、可以神兽修复操作，则依然可以继续使用MyISAM。
2.1存储
MyISAM会将表存储在两个文件中：数据文件和索引文件，分别以.MYD 和 .MYI为扩展名。MyISAM表可以包含动态或者静态行。MySQL会根据表的定义来决定采用何种行格式。MyISAM表可以存储的行记录数，一般受限于可用的磁盘空间，或者操作系统中单个文件的最大尺寸。
在MySQL5.0中，MyISAM表如果是变长行，则默认配置只能处理256TB的数据，因为指向数据记录的指针长度时6个字节、而在更早的版本中，指针长度默认是4字节，所以只能处理4GB的数据。而所有的MyQSL版本都支持8字节的指针。要改变LENGTH选项的值来实现，两者相乘就是表可能达到的最大值。修改这两个参数会导致重建整个表和表的所有索引，这可能需要很长时间才能完成执行。
2.2MyISAM特性
最为MySQL最早的存储引擎之一，MyISAM有一些已经开发出来很多年的特性可以满足用户的实际需求。
2.2.1 加锁与并发
MyISAM对整张表加锁，而不是针对行。读取时会对需要读到的所有表加共享锁，写入时则对表加排他锁。但是在表有读取查询的同时，也可以往表中插入新的记录（这被称为并发插入，CONCURRENT INSERT）
2.2.2 修复
对于MyISAM表，MySQL可以手工活自动执行检查和修复操作，但这里说的修复和师傅恢复以及崩溃恢复是不同的概念。执行表的修复可能导致一些数据丢失，而且修复操作时非常慢的。可以通过CHECK TABLE tableName 检查表的错误，如果有错误可以通过执行REPAIR TABLE tableName 进行修复。另外，如果MySQL服务器已经关闭，也可以通过myisamchk命令行工具进行检查和修复操作。
2.2.3 索引特性
对于MyISAM表，即使是BLOB和TEXT等长字段，也可以基于其前个字符创建索引。MyISAM也支持全文索引，这是一种基于分词创建的索引，可以支持复杂的查询。
2.2.4 延迟更新索引键
创建MyISAM表的时候，如果指定了DELAY_KEY_WRITE选项，在每次修改执行完成时，不会立刻将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区（in-memorykey buffer），只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入到磁盘。这种方式可以极大的提升写入性能，但是在数据库或者主机崩溃时会造成索引损坏，需要执行修复操作。延迟更新索引建的特性，可以在全局设置，也可以为单个表设置。
2.3 MyISAM压缩表
如果表在创建并导入数据以后，不会再进行修改操作，那么这样的表或许审核采用MyISAM压缩表。
可以使用myisampack对MyISAM表进行压缩（也叫打包）。压缩表时不能进行修改的（除非先将表解压，修改数据后在压缩）。压缩表可以极大的减少磁盘空间占用，因此可以减少磁盘I/O，从而提升查询性能。压缩表也支持索引，但索引也是只读的。
以现在的硬件能力，对大多数应用场景，读取压缩表数据时的解压带来的开销影响并不大，而减少I/O带来的好处则要大得多。压缩时表中的记录是独立压缩的，所以读取单行的时候不需要去解压整个表。
2.4 MyISAM 性能
MyISAM引擎设计简单，数据以紧密格式存储，所以在某些场景下的性能很好。MyISAM有一些服务器级别的性能扩展限制，比如对索引键缓冲区（key cache）的Mutex锁，MariaDB基于段（segment）的索引键缓冲区机制来避免该问题。但MyISAM最典型的性能问题还是表锁的问题，如果你发现所有的查询都长期处于Locked状态，那么毫无疑问就是表锁的问题。