存储引擎就是指表的类型以及表在计算机上的存储方式
show engines 查看存储引擎
InnoDB存储引擎：
（1）InnoDB是事务性数据库的首选引擎，支持事务ACID，简单地说就是支持事务完整性、一致性。
（2）InnoDB支持行级锁。行级锁可以在最大程度上支持并发，以及类似Oracle的一致性、多用户并发。
（3）InnoDB是为处理巨大数据量的最大性能设计，InnoDB存储引擎完全与Mysql服务器整合，InnoDB为在主内存中缓存数据和索引而维护它自己的缓冲池。
（4）InnoDB支持外键完整性约束，存储表中数据时，每张表的存储都按照主键顺序存放，如果没有在表定义时指定主键，InnoDB会为每一行生成一个6字节的ROWID，并以此作为主键。
（5）InnoDB支持崩溃数据自修复。InnoDB存储引擎中就是依靠redo log来保证的。当数据库异常崩溃后，数据库重新启动时会根据redo log进行数据恢复，保证数据库恢复到崩溃前的状态。
MyISAM存储引擎：
（1）MyISAM引擎不支持事务，所以对事务有要求的业务场景不能使用。
（2）其锁定机制是表级索引，虽然可以让锁定的实现成本很小，但是也同时大大降低了其并发性能。
（3）不仅会在写入的时候阻塞读取，MyISAM还会在读取的时候阻塞写入，但读本身并不会阻塞另外的读。
（4）只会缓存索引：MyISAM可以通过key_buffer缓存，以大大提高访问性能减少磁盘I/O，但是这个缓存区只会缓存索引，而不会缓存数据。
（5）适用于不需要事务支持（不支持）、并发相对较低（锁定机制问题）、数据修改相对较少（阻塞问题）、以读为主这类场景。
MEMORY存储引擎：
MEMORY存储引擎是MYSQL中的一类特殊存储引擎，使用存储在内存中的内容来创建表，而且所有数据也放在内存中。
（1）每个基于MEMORY存储引擎的表实际对应一个磁盘文件。该文件的文件名与表名相同，类行为frm类型。该文件中指存储表的结构，数据文件则存储在内存中。
（2）MEMORY默认使用哈希索引，速度比使用B型树索引快。如果想用B型树索引，可以在创建索引时指定。
（3）MEMORY存储引擎是把数据存到内存中，如果内存出现异常就会影响数据。如果重启或者关机，那么所有数据都会消失。
总结：每种存储引擎都有自己的优缺点，不能笼统地说谁比谁好。如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那么选择InnoDB有很大的优势。如果表主要是用于插入记录和读出记录，那么选择MyISAM能实现处理高效率。如果需要很快的读写速度，对数据的安全性要求低，可以选择MEMORY，它对表的大小有要求，不能建立太大的表。
索引使用的原则：
（1）表一定要有主键，显式定义主键且采用与业务无关的列以避免修改。InnoDB表在有主键时会自动将主键设为聚集索引，建议采用自增列来使数据顺序插入。
（2）关于合理添加索引，有一个通常的法则，即对于经常被查询的列、经常用于表连接的列、经常排序分组的列，需要创建索引。
（3）创建索引之前，还要查看索引的选择性（不重复的索引值和表的记录总数的比值）来判断这个字段是否合适创建索引。索引的选择性越接近于1，说明选择性越高，非常适合创建索引。
（4）组合索引（表中两个或者两个以上的列上创建的索引），一般把选择性高的列放在前面。组合索引字段数不建议超过5个，如果5个字段还不能极大地缩小row范围，那么肯定是设计有问题。
（5）合理利用覆盖索引（只需要通过索引就可以返回查询所需要的数据，不必在查到索引之后再回表查询数据）。禁止使用select *，只获取必要字段，指定字段能有效利用索引覆盖。
（6）使用explain判断SQL语句是否合理使用了索引，尽量避免Extra列出现Using File Sort、Using Temporary。
（7）单张表的索引数量建议控制在5个以内，索引太多也会浪费空间且降低修改数据的速度，影响性能。
（8）不建议在频繁更新的字段上建立索引。
（9）Where 条件中的索引列不能是表达式的一部分，避免在Where 条件中在索引列上进行计算或使用函数，因为这将导致索引不被使用而进行全表扫描。
（10）如果要进行join 查询，那么被join的字段必须类型相同并建立索引，因为join字段类型不一致会导致全表扫描。
（11）隐式类型转换会使索引失效，导致全表扫描。