在 MySQL 中,索引是在存储引擎层实现的,所以并没有统一的索引标准,即不同存储引擎的索引的工作方式并不一样。而即使多个存储引擎支持同一种类型的索引,其底层的实现也可能不同;
存储引擎采用B+树,每一行在磁盘中存储为一个数据块;
每一个索引在 InnoDB 里面对应一棵 B+ 树;
主键索引的叶子节点存的是整行数据;
非主键索引的叶子节点内容是主键的值;
基于非主键索引的查询需要多扫描一棵索引树(回表)。因此,我们在应用中应该尽量使用主键查询。对于某些高频查询,建立联合索引也可以避免回表,但索引的维护是需要代价的,因此需要权衡;
有业务逻辑的字段做主键,则往往不容易保证有序插入,这样写数据成本相对较高;
显然,主键长度越小,普通索引的叶子节点就越小,普通索引占用的空间也就越小,所以,从性能和存储空间方面考量,自增主键往往是更合理的选择;
由于覆盖索引可以减少树的搜索次数,显著提升查询性能,所以使用覆盖索引是一个常用的性能优化手段;
DML(INSERT | UPDATE | DELETE)
DDL(CREATE | DORP | ALTER|)
事务隔离级别:
在实现上,数据库里面会创建一个视图,访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下,这个视图是在事务启动时创建的,整个事务存在期间都用这个视图。在“读提交”隔离级别下,这个视图是在每个 SQL 语句开始执行的时候创建的。这里需要注意的是,“读未提交”隔离级别下直接返回记录上的最新值,没有视图概念;而“串行化”隔离级别下直接用加锁的方式来避免并行访问。
数据库涉及到全局锁、表锁和行锁,一些数据库引擎如InnoDB通过relog等方式可以达到全局锁的目的,就可以不适用全局锁。这个时候事务和线程很像,所以他也会出现死锁的情况。
在 InnoDB 事务中,行锁是在需要的时候才加上的,但并不是不需要了就立刻释放,而是要等到事务结束时才释放。这个就是两阶段锁协议。
在处理锁的问题时,为了避免阻塞,可以设置超时时长;
第一种启动方式,一致性视图是在第执行第一个快照读语句时创建的;
第二种启动方式,一致性视图是在执行 start transaction with consistent snapshot 时创建的。