数据库常见面试题汇总

数据库面试知识点汇总

1.简述关系型与非关系型数据库的区别？

1. 关系型数据库是依据关系模型来创建的数据库，所谓关系模型就是“一对一”、“一对多”、“对多对”等。常见的关系型数据库有Oracle、MySQL、SQL Server等。
2. 非关系型数据库主要基于“非关系型模型”，其中非关系型模型有：列模型、键值对模型、文档类模型。比如redis属于键值对模型。

关系型数据库的优点：

1. 易于维护：都是使用表结构，格式一致。
2. 使用方便：SQL语言通用，可用于复杂查询。
3. 复杂操作：支持SQL，可用于一个表以及多个表之间非常复杂的查询。

关系型数据库的缺点：

1. 读写性能比较差，尤其是海量数据的高效率读写。
2. 固定的表结构，灵活度稍欠。
3. 高并发读写需求，传统关系型数据库来说，硬盘I/O是一个很大的瓶颈。

非关系型数据库的优点：

1. 格式灵活：存储数据的格式可以是key,value形式、文档形式、图片形式等，使用灵活，应用场景广泛，而关系型数据库则只支持基础类型。
2. 速度快：nosql可使用硬盘或者随机存储器作为载体，关系型数据库只能使用硬盘。
3. 高拓展性
4. 成本低：nosql数据库部署简单，基本都是开源软件。

非关系型数据库的缺点：

1. 不提供sql支持，学习和使用成本较高。
2. 无事务处理。
3. 数据结构相对复杂，复杂查询方面稍欠。

2.简述为什么需要使用索引？

1. 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
2. 可以加快数据的检索速度，是创建索引的主要原因。
3. 减少磁盘IO，可以直接定位。
4. 通过使用索引，可以在查询过程中，使用优化隐藏器，提高系统的性能
5. 加速表与表的连接，特别是在实现数据的参考完整性方面特别有意义。

缺点：

1. 创建索引和维护索引需要耗费时间，时间随着数据量的增加而增加。
2. 索引需要占用物理空间，特别是聚簇索引，需要较大的空间。
3. 当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。

3.简述数据库索引采用B+树不采用B树的原因？

1. B+树更便于遍历：由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。
2. B+树的磁盘读写代价更低：B+树在内部节点上不包含数据信息，因此在内存页中能够存放更多的key。 数据存放的更加紧密，具有更好的空间局部性。因此访问叶子节点上关联的数据也具有更好的缓存命中率。
3. B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
4. B+树更适合基于范围的查询 ：B树在提高了IO性能的同时并没有解决元素遍历的效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。

4.简述MySQL索引有哪些类型？

1. 普通索引：最基本的索引，没有任何限制。
2. 唯一索引：索引列的值必须唯一，但可以有空值。可以创建组合索引，则列值的组合必须唯一。
3. 主键索引：是特殊的唯一索引，不可以有空值，且表中只存在一个该值。
4. 组合索引：多列值组成一个索引，用于组合搜索，效率高于索引合并。
5. 全文索引：对文本的内容进行分词，进行搜索。

5.简述什么是聚簇索引及其优缺点？

1. 聚簇索引并不是单独的索引类型，而是一种数据存储方式。
2. B+树索引分为聚簇索引和非聚簇索引，主键索引就是聚簇索引的一种，非聚簇索引有复合索引、前缀索引、唯一索引。
3. 在innodb存储引擎中，表数据本身就是按B+树组织的一个索引结构，聚簇索引就是按照每张表的主键构造一颗B+树，同时叶子节点中存放的就是整张表的行记录数据，也将聚簇索引的叶子节点成为数据页。
4. Innodb通过主键聚集数据，如果没有定义主键，innodb会选择非空的唯一索引代替。如果没有这样的索引，innodb会隐式的定义一个主键来作为聚簇索引。
5. 非聚簇索引又称为辅助索引，InnoDB访问数据需要两次查找，辅助索引叶子节点存储的不再是行的物理位置，而是主键值。通过辅助索引首先找到的是主键值，再通过主键值找到数据行的数据页，再通过数据页中的Page Directory找到数据行。
6. Innodb辅助索引的叶子节点并不包含行记录的全部数据，叶子节点除了包含键值外，还包含了相应行数据的聚簇索引键。一张表可有多个二级索引。

优点：

1. 数据访问更快，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据比非聚簇索引更快。
2. 聚簇索引对于主键的排序查找和范围查找速度非常快。

缺点：

1. 插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个自增的ID列为主键。
2. 更新主键的代价很高，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义主键为不可更新。
3. 二级索引访问要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据。

6.简述InnoDB与MyISAM实现索引方式的区别？

1. 首先两者都是用的是B+树索引，但二者的实现方式不同。
2. 对于主键索引，InnoDB中叶子节点保存了完整的数据记录，而MyISAM中索引文件与数据文件是分离的，叶子节点上的索引文件仅保存了数据记录的地址.
3. 对于辅助索引，InnoDB中辅助索引会对主键进行存储，查找时，先通过辅助索引的B+树在叶子节点获取对应的主键，然后使用主键在主索引B+树上检索操作，最终得到行数据；MyISAM中要求主索引是唯一的，而辅助索引可以是重复的，主索引与辅助索引没有任何区别，因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。

7.简述什么是聚簇索引与非聚簇索引？

1. 聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据。
2. 非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，MyISAM通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因。

8.主键索引是聚集索引还是非聚集索引？

1. 聚集索引决定了数据库的物理存储结构，而主键只是确定表格逻辑组织方式。这两者不可混淆！
2. 在InnoDB下主键索引是聚集索引，在MyISAM下主键索引是非聚集索引。

9.简述InnoDB为什么使用自增id作为主键？

1. MySQL底层使用是使用数据页为单位来存储数据的，一个数据页大小默认为16K，当数据页满了，就会申请新的数据页进行存储数据。
2. 如果主键为自增 id 的话，mysql 在写满一个数据页的时候，直接申请另一个新数据页接着写就可以了。
3. 如果主键是非自增 id，为了确保索引有序，mysql 就需要将每次插入的数据都放到合适的位置上。当往一个快满或已满的数据页中插入数据时，新插入的数据会将数据页写满，mysql 需要申请新的数据页，并且把上个数据页中的部分数据挪到新的数据页上。这就造成了页分裂，这个大量移动数据的过程是会严重影响插入效率。

10.简述为什么主键越小越好？

1. 主键占用空间越大，每个页存储的主键个数越少，路树就越少，B+树的深度会边长，导致IO次数会变多。
2. 辅助索引的叶子节点上保存的是主键 id 的值，如果主键 id 占空间较大的话，那将会成倍增加 mysql 空间占用大小。

11.简述数据库执行查询请求的过程？

1. 客户端请求：建立TCP连接。
2. 使用连接器进行连接管理：此时服务端会对客户端发来数据携带的主机信息、用户名、密码等信息进行验证，如果认证失败就会拒绝连接。（连接器）
   注： 当客户端连接服务端进程后，服务端进程会为其创建进程专门用于交互，当断开连接后，服务端不会立即进行销毁，而是会进行缓存，用于下次新的连接，这样可以不用频繁的创建和销毁线程，节省开销。
3. 缓存查询：服务端会对之前的请求结果进行缓存，若存在缓存直接返回，否则继续执行下一步。维护缓存的代价较大，因此在8.0版本后已删除缓存。
4. 语法解析：由于目前为止还未对文本解析，此时会对文本进行词法分析、语法分析、语义分析等过程，真正开始解析。（分析器）
5. 查询优化：主要对执行的sql优化选择最优的执行方案。（优化器）
6. 存储引擎：执行时会先看用户是否有执行权限，有才去使用这个引擎提供的接口。然后去引擎层获取数据返回，若开启查询缓存则会缓存查询结果。（执行器）

12.简述脏读、幻读、不可重复读的定义？

1. 脏读：指当一个事务正在访问数据，并且对数据进行了修改，而这种数据还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据还没有提交那么另外一个事务读取到的这个数据我们称之为脏数据。
2. 不可重复读：指在一个事务内，多次读同一数据。在这个事务还没有执行结束，另外一个事务也访问该同一数据，那么在第一个事务中的两次读取数据之间，由于第二个事务的修改第一个事务两次读到的数据可能是不一样的，这样就发生了在一个事务内两次连续读到的数据是不一样的，这种情况被称为是不可重复读。
3. 幻读：一个事务先后读取一个范围的记录，但两次读取的纪录数不同，我们称之为幻象读。（两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中）

13.简述数据库的隔离级别？

1. 读未提交：指一个事务读取另一个事务未提交的修改。，会发生脏读、不可重复读、幻读。
2. 读提交：指只能读到已经提交的内容。会发生不可重复读和幻读。是SQL Server和Oracle的默认隔离级别。
3. 可重复读：指当数据被读取时，不可进行update操作，保证多次读取的记录是相同的，解决了不可重复读的问题。但幻读是insert导致，不会避免。可重复读是MySQL的默认隔离级别。
4. 可串行化读：这是数据库最高的隔离级别，这种级别下，事务“串行化顺序执行”，也就是一个一个排队执行。这种级别下，“脏读”、“不可重复读”、“幻读”都可以被避免，但是执行效率奇差，性能开销也最大，所以基本没人会用。

14.简述MySQL可以从哪些方面做到性能优化?

1. 为搜索字段创建索引。
2. 避免使用 Select *，列出需要查询的字段。
3. 垂直分割分表，水平分割是分割记录，以一条记录/行为单位。垂直分割则是以列为单位，将列分割出去。
4. 选择正确的搜索引擎。
5. 实现数据库的主从同步，实现读写分离。
6. 添加合适的缓存机制，维护代价高。
7. 对冷热数据进行均分，减少单个库的压力，使整体性能达到更优。

15.简述MySQL为什么需要事务回滚机制？

1. 在MySQL中事务回滚通过日志完成，所有事务进行的修改都会先记录到回滚日志中，然后再对数据库中的对应行进行写入。当事务被提交后就无法回滚了。

   回滚日志的作用：

   1. 能够在发生错误或用户执行rollback时提供回滚的相关信息。
   2. 在整个系统发生崩溃、数据库进程直接被杀死后，当用户再次启动数据库进程时，还能够立刻通过查询回滚日志将之前未完成的事务进行回滚，这也就需要回滚日志必须先于数据持久化到磁盘上，是我们需要先写日志后写数据库的主要原因。

16.简述MySQL引擎InnoDB和MyISAM的区别？

InnoDB：

1. 是MySQL默认的事务型存储引擎，只有当需要它不支持的特性时，才会考虑使用其它的存储引擎。
2. 实现了四个标准的隔离级别，其中默认为可重复读，在可重复读的隔离级别下，通过MVCC（多版本并发控制协议）+ 间隙锁（Next-key Locking）防止幻读。
3. 主索引为聚簇索引，在索引中保存数据，从而避免直接读取磁盘，因此对查询性能有很大的提升。
4. 支持真正的在线热备份。其它存储引擎不支持在线热备份。
5. 支持行级锁，通过给索引项加锁来实现，即只有通过索引条件检索数据，才会使用行级锁，否则使用表锁。
6. InnoDB不会对表中行的总量进行预先统计，每次count需要遍历计算。

MyISAM：

1. 设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复操作，则依然可以使用它。
2. 提供了大量的特性，包括压缩表、空间数据索引等。
3. 不支持事务。
4. 不支持行级锁，只能对整张表加锁，读取时会对需要读到的所有表加共享锁，写入时则对表加排它锁。
5. 会实时保存数据库表中的总行数，计算快。

总结：

1. 事务：MyISAM不支持，InnoDB支持。
2. 锁级别： MyISAM 表级锁，InnoDB 行级锁及外键约束。
3. MyISAM存储表的总行数；InnoDB不存储总行数。
4. MyISAM采用非聚集索引，B+树叶子存储指向数据文件的指针。InnoDB主键索引采用聚集索引，B+树叶子存储数据。
5. 崩溃恢复: MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。

使用场景：

1. MyISAM适合：插入不频繁，查询非常频繁，如果执行大量的SELECT，MyISAM是更好的选择，没有事务。
2. InnoDB适合：可靠性要求比较高，或者要求事务； 表更新和查询都相当的频繁， 大量的INSERT或UPDATE。

17.数据库分库分表的原因？

1. 分库分表的目的在于减少数据库单库单表的负担，提高查询性能，缩短查询时间。
2. 分库分表分别水平切分和垂直切分。
3. 垂直切分：分为垂直分库和垂直分表，其中垂直分库是指根据业务的耦合度，将关联度较低的不同表存储于不同的库中，类似于大系统拆分为小系统；垂直分表是指基于数据库表中的列，将不常用的列进行划分成新表，可以使单个表中的数据量变少减少跨页，使得单个页中字段更多，使内存能够加载更多的数据，提高命中率，减少磁盘IO，提高性能。
4. 水平切分：水平切分是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。但只是库内分表，仅仅是解决了单表数据过大的问题，并没有把单表的数据分散到不同的物理机上，因此并不能减轻 MySQL 服务器的压力，仍然存在同一个物理机上的资源竞争和瓶颈，包括 CPU、内存、磁盘 IO、网络带宽等。
5. 使用哪种方式分库分表需要依据情况而定，比如数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。而如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。

18.简述什么是覆盖索引？

1. 如果一个索引包含所有需要查询的字段的值，我们就称 之为“覆盖索引”。
2. 对于InnoDB存储引擎来说，如果不是主键索引，那么辅助索引的叶子节点存储的是主键+辅助索引的列值，然后还需要进行回表操作。
3. 这样的话，会降低查询速度，因此，若使用辅助索引查询时，若查询得到的值和需要查询的结果列值时对应的（或者覆盖），则可以一直接使用其结果，不需要进行回表操作。

19.简述三大范式的特点?

1. 第一范式：指数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值相同，即无重复的列。
2. 第二范式：满足第一范式，还要求数据库表中的每个实例或行必须被唯一标识，满足实体的属性完全依赖于主关键字。
3. 第三范式：满足第二范式，还要求数据库表中不包含其他表中的非主关键字信息，即两个表中不存在相同的非主关键字信息，否则会造成数据冗余。

20.简述聚簇索引与非聚簇索引（辅助）的区别？

1. 聚簇索引的叶子节点存放的是主键值和数据行，支持覆盖索引；非聚簇索引的叶子节点存放的是主键值或指向数据行的指针。
2. 聚集索引就是以主键创建的索引，非聚集索引就是以非主键创建的索引。
3. 由于节子节点(数据页)只能按照一颗B+树排序，故一张表只能有一个聚簇索引。辅助索引的存在不影响聚簇索引中数据的组织，所以一张表可以有多个辅助索引。

21.简述事务的四大特性?

1. 原子性：指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须完全应用到数据库，如果操作失败则不能对数据库有任何影响。
2. 一致性：指事务开始前和结束后，数据库的完整性约束没有被破坏。
3. 隔离性：指当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
4. 持久性：指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

22.简述创建索引的注意事项？

1. 非空字段：索引字段不能有NULL，如果有NULL值将不会包含在索引中。
2. 索引字段越小越好：数据库的数据存储以页为单位一页存储的数据越多一次IO操作获取的数据越大效率越高。 唯一、不为空、经常被查询的字段 的字段适合建索引。
3. 取值离散大的字段：（变量各个取值之间的差异程度）的列放到联合索引的前面，可以通过count()函数查看字段的差异值，返回值越大说明字段的唯一值越多字段的离散程度高。
4. 限制创建索引的数量：对于存在大量更新操作的表，索引一般不超过3个。

23.为什么索引的数量不能太多？

1. 当对表中的数据进行增加、删除、修改时，同时需要动态维护索引，降低了整体的维护速度。
2. 索引需要占据物理空间，如果要建立聚簇索引，那么需要的空间就会更大，因为会将数据存储于叶子节点。
3. 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。

24.简述数据库的行级锁与表锁？
表锁：

1. 不会出现死锁，发生锁的冲突几率高，并发性低。
2. 存储引擎在进行SQL数据读写请求前，会对涉及到的表进行加锁。
3. 其中锁分为共享读锁和独占写锁：读锁会阻塞写，写锁会阻塞读和写。

行级锁：

1. 会出现死锁，发生锁的冲突几率低，并发性高。
2. InnoDB引擎支持行锁，与Oracle不同，MySQL的行锁是通过索引加载的，也就是说，行锁是加在索引响应的行上的，要是对应的SQL语句没有走索引，则会全表扫描，行锁则无法实现，取而代之的是表锁，此时其它事务无法对当前表进行更新或插入操作。

行级锁注意事项：

1. 行级锁必须有索引才能实现，否则会自动锁全表，那就不是行锁了。
2. 两个事务不能锁同一个索引。
3. insert，delete，update在事务中都会自动默认加上排它锁。

行锁的适用场景：

1. 避免不可重复读的场景。

25.简述为什么MySQL索引使用B+树而不用hash表和B树？

1. 利用Hash需要把数据全部加载到内存中，如果数据量大，是一件很消耗内存的事，而采用B+树，是基于按照节点分段加载，由此减少内存消耗。
2. 和业务场景有段，对于唯一查找（查找一个值），Hash确实更快，但数据库中经常查询多条数据，这时候由于B+数据的有序性，与叶子节点又有链表相连，他的查询效率会比Hash快的多。
3. b+树的非叶子节点不保存数据，只保存子树的临界值（最大或者最小），所以同样大小的节点，b+树相对于b树能够有更多的分支，使得这棵树更加矮胖，查询时做的IO操作次数也更少。

26.简述B树的结构及特点？
对于一个M阶的B树有以下特征：

1. 第一任何非叶子节点最多只有M个儿子，且M > 2;
2. 根节点的儿子数量范围为[2,M]；
3. 除根节点 以外的非叶子节点的儿子数量为[M/2，M]，向上取整，M/2是由于当某个节点达到M个节点信息时，会进行拆分为两个叶子节点。
4. 非叶子节点的关键字数量 = 叶子数量 - 1；
5. 所有的叶子节点位于同一层；
6. k个关键字把节点拆成k+1段，分别指向k+1个儿子，同时满足查找树的大小关系；
7. 每个节点除了存储索引外还保存该索引对应数据的地址；

27.简述B+树的结构及特点？
对于一个M阶的B树有以下特征：

1. 有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。
2. 所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接，形成一个有序的链表。
3. 所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。
4. 由于每个节点只存索引，因此每个页存储的数据变多，可减少IO次数。

28.数据库如何保证事务的ACID特性？

1. 原子性：使用innodb的undo log（回滚日志），undo log记录了回滚需要的信息，当事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。
2. 隔离性： 使用悲观锁和乐观锁对事务处理。
3. 持久性：使用innodb的redo log（重写日志）， 记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置);当做数据修改的时候，不仅在内存中操作，还会在redo log中记录这次操作。当事务提交的时候，会将redo log日志进行刷盘(redo log一部分在内存中，一部分在磁盘上)。当数据库宕机重启的时候，会将redo log中的内容恢复到数据库中，再根据undo log和binlog内容决定回滚数据还是提交数据。
4. 一致性：通过原子性、隔离性、持久性来保证一致性。

29.简述使用redo的好处?

1. redo log体积小，毕竟只记录了哪一页修改了啥，因此体积小，刷盘快。
2. redo log是一直往末尾进行追加，属于顺序IO。效率显然比随机IO来的快。

30.如何解决数据库高并发问题？

1. 在web服务框架中加入缓存。在服务器与数据库层之间加入缓存层，将高频访问的数据存入缓存中，减少数据库的读取负担。
2. 增加数据库索引，进而提高查询速度。（不过索引太多会导致速度变慢，并且数据库的写入会导致索引的更新，也会导致速度变慢）
3. 主从读写分离，让主服务器负责写，从服务器负责读。
4. 将数据库进行拆分，使得数据库的表尽可能小，提高查询的速度。
5. 使用分布式架构，分散计算压力。

31.简述联合索引的最左匹配原则?

1. MySQL建立联合索引时遵循最左匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。
2. 对于联合索引而言构造B+树，会依次从左往右按顺序比较进行键值插入，遇到范围查找就会停止，剩下的字段就会失效无法使用索引。

32.简述SQL语句的优先级顺序？

1. from:需要从哪个数据表检索数据
2. join：联合多表查询返回记录时，并生成一张临时表
3. on：在生成临时表时使用的条件
4. where:过滤表中数据的条件
5. group by:如何将上面过滤出的数据分组
6. having:对上面已经分组的数据进行过滤的条件
7. select:查看结果集中的哪个列，或列的计算结果
8. order by :按照什么样的顺序来查看返回的数据

33.简述索引失效的情况？

1. like 以%开头，索引无效；当like前缀没有%，后缀有%时，索引有效。
2. or语句前后没有同时使用索引。当or左右查询字段只有一个是索引，该索引失效，只有当or左右查询字段均为索引时，才会生效。
3. 组合索引，不是使用第一列索引，索引失效。
4. 数据类型出现隐式转化。如varchar不加单引号的话可能会自动转换为int型，使索引无效，产生全表扫描。
5. 在索引列上使用 IS NULL 或 IS NOT NULL操作。
6. 在索引字段上使用not，<>，!=。不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。 优化方法： key<>0 改为 key>0 or key<0。
7. 对索引字段进行计算操作、字段上使用函数。
8. 当全表扫描速度比索引速度快时，mysql会使用全表扫描，此时索引失效。

如何检查索引是否失效：

1. 可以使用explain命令加在要分析的sql语句前面，在执行结果中查看key这一列的值，如果为NULL，说明没有使用索引。

34.简述什么情况下不应该创建索引？

1. 对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
2. 对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
3. 对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
4. 当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。