参考

概述

Mysql支持常用的4种存储引擎：Myisam、InnoDB(默认)、Memory、Merge

SHOW ENGINES;查看，Mysql支持多种存储引擎。

使用场景：多读少写，不需要事务、外键，也不容易服务器异常的场景
Myisam缓存机制
每次通过索引读取数据的时候，Mysql都会缓存这个 IndexPage 到内存当中，这个内存块的大小由 key_buffer_size（默认 8M）决定，记录了这个索引块里面的所有数据对应的物理地址信息，并且mysql有一个LRU队列去管理这个缓存块。
包括修改的时候，也是直接修改这个缓存块（同时会记录日志），并且标记这个page为dirty，当从LRU队列里面移除的时候，如果Dirty则需要写回到硬盘上。
因为缓存的只是索引和物理存储地址，而不缓存真正的数据，所以和Innodb相比，相同大小的缓存空间，Myisam可以缓存更多的索引。

When read, a MyISAM table's indexes can be read once from the .MYI file and loaded in the MyISAM Key Cache (as sized by key_buffer_size).

结论：在多读少写的业务场景下，Myisam的read的速度快好几倍。但是在有读有写或者多读少写的业务场景下，Myisam因为是表锁会阻塞，读和写都慢。

非聚簇索引一次lookup:在非主键索引的Query的业务场景下，Myisam只需要一次B+树 key lookup，就可以读取到data的物理地址，再一次IO读取，就可以获取到磁盘的数据信息，但是 InnoDB却需要2次索引树查找，这个都是不在一个物理page的查找，所以Myisam理论上在这一点设计上差不多快一倍。
Myisam没有MVCC，在任意时间节点，一个数据就只有1个值，而Innodb就可能同时存在多个版本，加大了搜索筛选条件。
Myisam可以更好的利用缓存：因为索引和数据是分离的，只缓存索引（索引值里面有key值和dataAddress），然后再一次IO读取，就可以捞取到数据。
但是Innodb因为数据和索引是存在一起的，必须同时缓存相应的索引和数据，所以相同缓存空间下，InnoDB可以缓存的数据量更少，缓存的命中率更低，但是一旦命中，则无需IO操作，可以直接返回数据。

数据存储位置：在 %datadir%/databaseName
默认一个page的大小是16k

Myisam的存储结构比较独立，可以通过直接拷贝这3个文件，来实现表数据的跨库迁移，甚至可以是跨操作系统的迁移

共享表空间以及独占表空间都是针对数据的从物理意义上来讲：

共享表空间: 会把表集中存储在一个系统表空间里。即每一个数据库的所有表的数据，索引文件全部放在一个文件中。该文件目录默认的是服务器的数据目录。默认的文件名为:ibdata1 初始化为10M。
独占表空间: 每一个表分别创建一个表空间，这时。在对应的数据库目录里每一个表都有.ibd文件(这个文件包括了单独一个表的数据内容以及索引内容)

用来做分表用的，多个结构相同的表，虚拟出一个merge表，可单独取操作子表来实现高性能，通知也支持操作merge表来实现，逻辑上统一的数据。

InnoDB只有在走索引查询加锁时才是行锁，否则都是表锁
例如User表主键 id，但是name字段没有索引，事务A 通过非索引字段 name来查询 huangzs的用户，并且锁定该数据（可能有多个 huangzs用户），因为name字段没有索引，所以是表锁
在没有commit之前，开启事务B，尝试修改 name=’huang’的操作是不能执行的，因为当前表被锁住了

TXA：
begin;
update user set memo ='hzs' where name='huangzs'
TXB:
begin;
update user set memo ='hzs' where name='huang'

行级锁的正确使用:查询条件是通过主键字段进行行级锁的，所以可以并发的修改数据

TXA：
begin;
update user set memo ='hzs' where id=500;
TXB:
begin;
update user set memo ='hzs' where id=501;

select的时候，只有 lock in share mode 或者 for update 才会锁定数据，没有限定词的话，默认是直接读取的，不存在竞争。也就是一行数据即使加锁了，直接select也可以查的到
InnoDB死锁了也不用怕，去倒杯水就好了：mysql 默认有innodb_lock_wait_timeout：50s的设置，超过50s会自动释放锁