搜索引擎和索引
MyISAM
MyISAM 使用的是B+Tree 作为索引结构<br>同时MyISAM 的B+Tree也是非聚集索引<br>
非聚集索引：指的是索引文件和数据分开存储
MyISAM 的 B+Tree 叶子节点的data域里存放的是数据记录的地址，<br>也就是数据在磁盘中的地址（例如：0x07）<br>
MyISAM 的主索引和辅助索引结构是一样的
InnerDB
InnerDB 使用的也是 B+Tree 作为索引结构，<br>InnerDB 的 B+Tree 和 MyISAM 的 B+Tree 结构非常不同，<br>InnerDB 的 B+Tree 是聚集索引结构
聚集索引：相对于MyISAM，聚集索引的索引和数据是在一起的<br>
InnerDB 的 B+Tree 叶子节点的data域里面直接存放了索引对应的数据，<br>InnerDB 索引的 key 用的是索引的主键（primary key）
InnerDB 的辅助索引，其索引结构上的key是数据，而data域是主键索引的值
索引相关问题
索引的使用顺序，检索顺序
1：首先使用辅助索引检索，获取主键
2：使用主键检索主键索引，或者具体数据
索引长度问题
1：索引字段不要过长，因为辅助索引使用的是数据做索引，字段过长索引也会过长<br>
2：主键不要过长，与上面的同理，过长的主键会直接影响辅助索引和主键索引，<br>直接导致索引过大
InnerDB 可不可以没有主键
不可以没有主键，<br> 主键所以直接使用主键作为索引，<br> 辅助索引最终指向的也是主键
InnoDB 没有主键会怎么样
- 如果定义了主键，那么InnoDB会使用主键作为聚簇索引 <br>- 如果没有定义主键，那么会使用第一非空的唯一索引（NOT NULL and UNIQUE INDEX）作为聚簇索引 <br>- 如果既没有主键也找不到合适的非空索引，那么InnoDB会自动生成一个不可见的名为ROW_ID的列名为GEN_CLUST_INDEX的聚簇索引，该列是一个6字节的自增数值，随着插入而自增<br>
索引优化
最左前缀
当查询条件精确匹配索引的左边连续一个或几个列时，索引可以被用到
全列匹配
当按照索引中所有列进行精确匹配（这里精确匹配指“=”或“IN”匹配）时，索引可以被用到
避免
查询条件用到了索引中列的精确匹配，但是中间某个条件未提供
查询条件没有指定索引第一列
匹配某列的前缀字符串
范围查询
查询条件中含有函数或表达式
索引和锁的关系
mysql innodb的锁是通过锁索引来实现的。
典型的排它锁：select for update <br>
如果字段没有索引，即使使用wehre条件也会进行表级锁
如果有索引，会锁定对应where条件中索引值的所有行，<br>可理解为对该索引值进行了索引（所以即使另一事务查询的是其他行，但因为索引值形同们也会被锁住。）<br>
有索引，而且使用了不同的索引值查数据，但是查询 的结果是同一行，可以理解为真正的数据行锁。
隔离级别
事务问题
脏读（Dirty Read）
一个事务读到了另一个未提交事务修改过的数据
不可重复读（Non-Repeatable Read）
行锁
隔离级别
读未提交（READ UNCOMMITTED）
在读未提交隔离级别下，事务A可以读取到事务B修改过但未提交的数据。<br><br>可能发生脏读、不可重复读和幻读问题，一般很少使用此隔离级别。
读已提交（READ COMMITTED）
在读已提交隔离级别下，事务B只能在事务A修改过并且已提交后才能读取到事务B修改的数据。
读已提交隔离级别解决了脏读的问题，但可能发生不可重复读和幻读问题，一般很少使用此隔离级别。
可重复读（REPEATABLE READ）
在可重复读隔离级别下，事务B只能在事务A修改过数据并提交后，自己也提交事务后，才能读取到事务B修改的数据。
可重复读隔离级别解决了脏读和不可重复读的问题，但可能发生幻读问题。
提问：为什么上了写锁（写操作），别的事务还可以读操作？
因为InnoDB有MVCC机制（多版本并发控制），可以使用快照读，而不会被阻塞。
可串行化（SERIALIZABLE）
各种问题（脏读、不可重复读、幻读）都不会发生，通过加锁实现（读锁和写锁）。
mvcc
多版本并发控制，数据库层面的设计，用于控制事务在多线程下的安全
MVCC的实现是通过undo log和read view来实现的
redo log负责记录修改数据
undo log负责记录修改步骤
innodb引擎下的表，每个数据行都有隐藏的两列
trx_id：事务id
roll_pointer：指针，指向上一次的修改，用于回滚操作
如果不存在主键的话，还会有第三列row_id，在没有主键的情况下默认生成的主键；
