MySQL（面试问题）

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_35">mysql锁有哪些

锁	范围	用途
全局锁	整个数据库	全库逻辑备份
表锁	表	表的读写
元数据锁	表	读锁：保证用户对表中数据进行增删改查时，其他线程对表结构进行更改。写锁：修改表的结构。
意向锁	表	意向锁，其实什么也没锁，主要为了快速判断表里是有记录被加锁。
AUTO-INC锁	表	自增锁，用于自增的字段。
记录锁	行 / 记录	分为：X（写锁）和 S（读锁）。对记录的读写
间隙锁	行	范围锁，锁定一个范围，例如（3,5），那么其他事务就无法插入4这条记录。间隙锁之间是兼容的，即两个事物可以同时持有包含相同范围的间隙锁，因为间隙锁主要是为了解决可重复读隔离级别下的幻读现象。
临键锁	行	是记录锁和间隙锁的结合，锁定一个范围，并锁定记录本身。例如临键锁（3,5]，那么其他事务就无法插入4这条记录，也无法修改5这条记录。
插入意向锁	行	表明事务想往某个范围内插入数据。