索引类型主键索引唯一索引普通索引组合索引全文索引索引采用的数据结构B+树Hash索引的匹配方法全值匹配 (3个字段组合索引查3个字段)匹配最左前缀 (3个字段组合索引查2个字段) “最左匹配”原则，存储引擎不能使用范围条件右边的索引列。mysql会一直向右匹配直到遇到范围查询(>、 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。匹配列前缀 (like '赵%')匹配范围值精确匹配某一列，并范围匹配另外一列 （组合索引）只访问索引的查询（本质是覆盖索引）面试技术名词回表覆盖索引最左匹配（组合索引时）索引下推：有了索引下推优化，可以在有like条件查询的情况下，减少回表次数。对于user_table表，我们现在有（username,age）联合索引 ， select * from user_table where username like '张%' and age > 10 如果没有索引下推优化（或称ICP优化），当进行索引查询时，首先根据索引来查找记录，然后再根据where条件来过滤记录；在支持ICP优化后，MySQL会在取出索引的同时，判断是否可以进行where条件过滤再进行索引查询，也就是说提前执行where的部分过滤操作，在某些场景下，可以大大减少回表次数，从而提升整体性能。
常见树的特点B 树介绍
B 树是为了磁盘存储设备而设计的一种多叉平衡查找树。（相对于二叉，B树每个内结点有多个分支，即多叉）
首先我们介绍一下一棵 m 阶B-tree的特性
m 阶的定义：一个节点能拥有的最大子节点数来表示这颗树的阶数
举个例子：如果一个节点最多有 n 个key，那么这个节点最多就会有 n+1 个子节点，这棵树就叫做 n+1（m=n+1）阶树;
B-树与B+树的区别B-树可以在非叶子结点命中，越靠近根节点的记录查找时间越快，只要找到关键字即可确定记录的存在； B+树只有达到叶子结点才命中；B-树的关键字和记录是放在一起的，叶子节点可以看作外部节点，不包含任何信息；B+树的非叶子节点中只有关键字和指向下一个节点的索引，数据只放在叶子节点中。B+树：叶子节点，有指向临近叶子节点的指针，方便顺序遍历， 范围查找。B+树：所有关键字都在叶子结点出现，叶子结点相当于是存储（关键字）数据的数据层；InnoDB索引与MyISAM索引区别第一个重大区别是，MyISAM索引文件和数据文件是分离的； InnoDB的数据文件本身就是索引文件， InnoDB索引B+树的叶节点data域保存了完整的数据记录。 这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。第二个与MyISAM索引的不同是InnoDB的辅助索引data域，存储记录主键，而不是地址。使用InnoDB引擎要注意的点因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。使用短的数据类型。在InnoDB中不要用非单调的字段作为主键。因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。为什么说B+树比B树更适合数据库索引？
1、 B+树的磁盘读写代价更低：操作系统按磁盘快预读数据，B+树的内部节点更小，一个磁盘盘块中可容纳的内部节点更多，IO次数会更少。B+树更加扁平遍历树时IO次数少。
2、B+树的查询效率更加稳定：关键字的查找必须走一条从根结点到叶子结点的路径，路径长度相同，使每一次数据的查询效率相同。
3、B+树更加适合做顺序遍历、区间查询：由于B+树的数据都存储在叶子结点中，有指针指向临近叶子节点，方便顺序扫表，适合做区间查询。
但是B树因为其分支结点同样存储着数据，需要进行一次中序遍历按序来扫表。所以B+树更加适合区间查询的情况，所以通常B+树用于数据库索引。
索引设计的原则适合加索引的列是出现在where条件中的列，或者join子句中指定的列；优先使用短的列做索引，如果对长字符串列进行索引，应该指定一个前缀长度，这样能够节省大量索引空间；不要过度索引。索引需要额外的磁盘空间，并降低写操作的性能。基数较大的列，如比性别列，只有0与1，索引效果很差，没有必要在此列建立索引；根据where子句来分析，合理创建组合索引，使用“最左匹配”原则，发挥“覆盖索引”特点，减少“回表”；根据where子句来分析，合理创建组合索引，使用“索引下推”思路，可以在有like条件查询的情况下，减少回表次数。使用 explain命令，查看执行计划，分析索引使用情况并进行优化。索引优化具体事项不要在索引列上做任何计算，比如使用函数、自动或手动进行类型转换，都会导致索引失效，从而进行全表扫描。mysql在使用不等于（!=或者）的时候无法使用索引，会导致全表扫描。mysql where条件中避免使用，is null，is not null 因为无法使用索引。mysql where条件，like以通配符开头（like '%aaa'）索引失效会变成全表扫描操作。减少查询返回的列的数量，可减少传输的数据量 。减少select * 语句，发挥“覆盖索引”的优势（只访问索引的查询（索引列包含查询列））innodb引擎，使用自增字段作为主键，避免B+树索引的分裂 。字符串不加单引号会导致索引失效，更准确的说是类型不一致会导致失效。比如字段email是字符串类型的，使用WHERE email=99999 则会导致失败，应该改为WHERE email='99999'。在查询条件中使用OR连接多个条件会导致索引失效，除非OR链接的每个条件都加上索引，这时应该改为两次查询，然后用UNION ALL连接起来。Mysql 讲一下 页锁、行锁、表锁
最全MySQL锁讲解：页锁、共享锁、行锁、表锁、悲观锁、乐观锁
Mysql 悲观锁 和 乐观锁
（1）悲观锁：顾名思义就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。
传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
（2）乐观锁： 顾名思义就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。
乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
（3）悲观锁 和 乐观锁的区别：
两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
Mysql 什么时候使用表锁
对于InnoDB引擎，在绝大部分情况下都应该使用行级锁，因为事务和行锁往往是我们之所以选择InnoDB表的理由。但在个别特殊事务中，也可以考虑使用表级锁。
当然，应用中这两种事务不能太多，否则，就应该考虑使用MyISAM引擎了。
Mysql 表锁和行锁应用场景Mysql的四种隔离级别
Read Uncommitted（读取到未提交内容）（会发生：脏读、不可重复读、幻读）
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
Read Committed（读取提交内容 或 不可重复读）（会发生：不可重复读、幻读）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
Repeatable Read（可重复读）（会发生：幻读）（是mysql的默认隔离级别。 ）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
Serializable（可串行化）（会发生：无）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。
说一下Mysql 的MVCC
多版本并发控制（MVCC，Multiversion Concurrency Control）
MVCC使得大部分支持行锁的事务引擎，不再单纯的使用行锁来进行数据库的并发控制，取而代之的是把数据库的行锁与行的多个版本结合起来，只需要很小的开销,就可以实现非锁定读，从而大大提高数据库系统的并发性能。
MVCC工作过程
InnoDB的MVCC，是通过在每行纪录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存了行的过期时间（或删除时间），当然存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行纪录的版本号进行比较。在REPEATABLE READ隔离级别下，MVCC具体的操作如下：
undo log
在不考虑redo log 的情况下利用undo log工作的简化过程为：
1）为了保证数据的持久性数据要在事务提交之前持久化；
2）undo log的持久化必须在在数据持久化之前，这样才能保证系统崩溃时，可以用undo log来回滚事务；
MVCC优缺点
MVCC在大多数情况下代替了行锁，实现了对读的非阻塞，读不加锁，读写不冲突。缺点是每行记录都需要额外的存储空间，需要做更多的行维护和检查工作。
1.MVCC手段只适用于Msyql隔离级别中的读已提交（Read committed）和可重复读（Repeatable Read）。
2.MVCC主要作用于事务性的，有行锁控制的数据库模型。
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： lzxmw777
