MySQL用了什么索引结构
B+ 树
B+树的优势
对比B树，B+树的数据放在叶子节点，非叶子节点存放索引，而B树中，行数据放在非叶子节点中。相比之下，B+一次读入的索引节点更多，减少IO次数，缩短查询时间。
对比二叉树，B+树的树高更低，树高代表了磁盘IO次数，更低的树所需要的IO次数更少。
对比Hash，hash不适合做范围查询，hash存在冲突问题。
什么是联合索引的最左匹配
多个字段建立联合索引时，会有一个顺序，例如 a、b、c 三个字段建立联合索引，如果我的查询条件是：where a = 1 and b = 1 and c = 1。这时查询会走联合索引，如果查询条件是：where b = 1 and c = 1。这时，查询条件不符合最左匹配原则，不会走联合索引。
也就是说，我们的查询条件要尽量符合联合索引的排列顺序a、b、c，避免索引失效。
主要因为，联合索引是先将a进行排序，再对b排序、再对c排序，这就导致a是全局有序的，b、c是局部有序的。
给了个sql a=1 and b>=2 and c=3判断哪几个字段走了索引
应该是a、b走了索引，c没走索引。（不确定）
什么时候用索引，索引失效场景
建立索引
如果对某一字段进行频繁查询时，可以建立索引。
被作为条件查询的字段
频繁需要排序的字段（索引已经排序，这样查询可以利用索引的排序，加快查询的速度）
被频繁用于连接的字段，提高多表查询效率
索引失效：对索引使用函数，例如：length(id)
对索引进行运算，例如：ID - 1 = 10（这种看起来有点有病，后面版本的MySQL对这种情况进行了优化，不会导致索引失效）
隐式类型转换。当操作符左右两边的数据类型不一致时，会发生隐式类型转换。例如 num = '123'
使用联合索引时，没有符合最左匹配
使用索引时，使用了左注释，或者右注释，即：like %aa 或者 like %a%
查询条件中，使用了or，并且or的前后条件中，有一个列没有索引。
联合索引（id,price,states）selsect * from 商品表 where id = 1 and price > 2 and states = 1走哪些索引
走了id、price
OR操作符往往难以使用联合索引where id = 1 and price > 2 or states = 1 不走索引
mysql锁有哪些
| 锁 | 范围 | 用途 |
|---|---|---|
| 全局锁 | 整个数据库 | 全库逻辑备份 |
| 表锁 | 表 | 表的读写 |
| 元数据锁 | 表 | 读锁 ：保证用户对表中数据进行增删改查时，其他线程对表结构进行更改。写锁：修改表的结构。 |
| 意向锁 | 表 | 意向锁，其实什么也没锁，主要为了快速判断表里是有记录被加锁。 |
| AUTO-INC锁 | 表 | 自增锁，用于自增的字段。 |
| 记录锁 | 行 / 记录 | 分为：X（写锁）和 S（读锁）。对记录的读写 |
| 间隙锁 | 行 | 范围锁，锁定一个范围，例如（3,5），那么其他事务就无法插入4这条记录。间隙锁之间是兼容的，即两个事物可以同时持有包含相同范围的间隙锁，因为间隙锁主要是为了解决可重复读隔离级别下的幻读现象。 |
| 临键锁 | 行 | 是记录锁和间隙锁的结合，锁定一个范围，并锁定记录本身。例如临键锁（3,5]，那么其他事务就无法插入4这条记录，也无法修改5这条记录。 |
| 插入意向锁 | 行 | 表明事务想往某个范围内插入数据。 |
什么时候用记录锁，什么时候用表锁，（这里提示where语句条件下什么时候用）
这个问题暂时不会。。。。。。。。。。
全表扫描的时候用表锁
where语句没有使用索引，要进行全表扫描的时候用表锁？？