数据库面试习题（下）

索引

1，何为索引？有什么作用

索引 是一种 数据结构，用于快速查找、插入和删除 数据库表 中的 数据。在 MySQL 中，索引 可以显著提高 查询性能，特别是在处理大量 数据 时。索引 的作用类似于书籍的 目录，可以帮助 数据库引擎 快速定位到所需的 数据。

索引 的 优点：

1. 提高查询速度：通过创建 索引，数据库引擎 可以快速定位到所需的 数据，避免 全表扫描，从而提高 查询速度。
2. 加速表的连接：在使用多个 表 进行 连接查询 时，如果 连接列 上有 索引，可以加快 连接速度。
3. 辅助排序和分组：索引 可以帮助 数据库引擎 在执行 排序 和 分组操作 时更快地定位到所需的 数据。
4. 唯一性约束：使用 唯一索引 可以确保 表 中的 数据 在指定 列 上具有 唯一性。

索引 的 缺点：

1. 占用存储空间：索引 需要占用额外的 存储空间，特别是在处理 大型表 时，可能会导致 存储空间 的增加。
2. 插入、删除和更新操作的性能下降：在 插入、删除 和 更新数据 时，数据库引擎 需要维护 索引 的 一致性，这可能会导致 性能下降。特别是在 高并发 的情况下，对 索引列 进行频繁 修改 可能会导致 锁定 和 阻塞问题。
3. 增加查询复杂度：在使用 索引 进行 查询 时，数据库引擎 需要花费更多的时间来分析和优化 查询计划。这可能会导致 查询复杂度 的增加，并降低 查询性能。

在设计和使用 索引 时，需要根据具体情况 权衡 其 优缺点，并根据实际需求创建合适的 索引。合理的 索引策略 可以提高 查询性能 和 数据访问速度，而不合理的 索引策略 可能导致 性能下降 和 存储空间 的浪费。

速记

索引本是好结构，增删查找快如溜。
MySQL 里作用牛，数据量大不用愁。
好比目录翻书优，引擎定位不犯忧。
优点多多要记熟，查询加速没拦阻。
全表扫描不再有，连接排序也优秀。
唯一约束保数据，索引帮你把关守。
不过缺点也得瞅，空间占用要增收。
增删改慢性能丢，并发修改易卡喉。
查询分析时间久，复杂度高让人愁。
设计使用要权衡，合理策略才是优。
性能提升乐无忧，乱建索引把坑留。

2，主键和候选键有什么区别？

主键 和 候选键 都是 数据库表 中的 关键属性，它们在 数据管理 和 查询 中起着重要作用。以下是 主键 和 候选键 的区别：

1. 主键（Primary Key）：主键 是 表 中的一个或多个 列 的组合，用于唯一标识 表 中的每一行 数据。主键 具有以下特点：

• 唯一性：主键值 在整个 表 中必须是唯一的，不允许重复。
• 非空性：主键列 不能包含空值（NULL）。
• 不可变性：一旦设定了 主键，就不能改变。
• 主键 可以是一个单独的 列，也可以是多个 列 的组合。

2. 候选键（Candidate Key）：候选键 是指可以唯一标识 表 中每一行 数据 的 列 或 列组合。候选键 具有以下特点：

• 唯一性：候选键值 在整个 表 中必须是唯一的，不允许重复。
• 可以为空：候选键列 可以包含空值（NULL）。
• 可变性：候选键列 的值可以改变。
• 一张 表 中可以有多个 候选键。

可以看出，主键 和 候选键 的主要区别在于 非空性 和 不可变性。主键 必须是非空的，且一旦设定就不能改变，而 候选键 可以包含空值，并且其值可以改变。此外，一张 表 中只能有一个 主键，但可以有多个 候选键。在实际应用中，通常会选择其中一个 候选键 作为 主键，以便更有效地管理和查询 数据。

速记

主键候选键很关键，数据管理它来管。
先讲主键的特点，唯一标识每一行。
值不重复不能空，一旦设定不能动。
单列多列都可用，数据查询更轻松。
再看候选键模样，唯一标识也很棒。
不同之处要记详，允许为空能变样。
表中可以有多个，各有各的好用场。
主键候选键有别，非空可变要分别。
一表只能一主键，候选多个任挑选。
候选挑一当主键，数据管理更完善。

3， 索引类型

索引 是 MySQL 中用于快速查找、插入和删除 数据 的 数据结构。以下是几种常见的 索引类型：

1. 唯一索引（Unique Index）：唯一索引 要求 索引列 的值在整个 表 中必须是唯一的，不允许重复。它可以用于 单列 或 多列，并可以用于 非主键列。
2. 主键索引（Primary Key Index）：主键索引 是一种特殊的 唯一索引，用于唯一标识 表 中的每一行 数据。它只能用于一个 列，并且该 列 不能包含空值（NULL）。在 MySQL 中，主键索引 同时也是 聚簇索引，即 数据 按照 主键 的顺序存储在 磁盘 上。
3. 单列索引（Single-Column Index）：单列索引 是只对单个 列 创建的 索引。它可以用于任何 数据类型，包括 字符串、数字、日期 等。单列索引 可以提高 查询性能，特别是在对该 列 进行频繁 查询 时。
4. 组合索引（Composite Index）：组合索引 是由多个 列 组成的 索引，可以用于 多列联合查询 和 排序操作。组合索引 可以提高 查询性能，但需要注意 列 的顺序和 选择性，以及避免 冗余索引 的问题。在使用 组合索引 时，应该尽量使 查询语句 中的 列 与 索引列 的顺序一致，以便充分利用 索引。
5. 全文索引（Full-Text Index）：全文索引 主要用于 文本搜索，支持 自然语言查询 和 布尔查询。它只能用于 CHAR、VARCHAR 和 TEXT 类型的 列，并且只能在 MyISAM 和 InnoDB 引擎的 表 中创建。全文索引 可以提高 文本搜索 的 性能，并提供更灵活的 查询方式。
6. 空间索引（Spatial Index）：空间索引 用于 地理空间数据 的 查询，支持在二维 地理空间数据 上的各种操作，如 范围查询 和 距离计算。空间索引 只能用于 地理空间数据类型，如 Point、LineString 和 Polygon 等。它可以提高 地理空间数据查询 的 性能，并提供更灵活的 查询方式。

在选择 索引类型 时，需要根据 数据类型、查询需求 和 表 的 结构 进行综合考虑。合理的 索引策略 可以提高 查询性能 和 数据访问速度，而不合理的 索引策略 可能导致 性能下降 和 存储空间 的浪费。

速记

MySQL索引有门道，快速查插删有效。下面类型要记牢：
唯一索引值独好，单列多列非主妙；
主键索引身份标，单列非空聚簇牢；
单列索引作用高，各型数据都照料；
组合索引多列搞，查询排序呱呱叫，列序选择要计较；
全文索引搜文巧，自然布尔都用到，MyISAM和InnoDB里找；
空间索引地理妙，范围距离都能搞，地理类型别用错了。
选好类型很重要，性能存储要协调，合理策略别瞎搞，不然浪费没处逃。

4，主键、外键和索引的区别？

主键、外键 和 索引 都是 数据库表 中的重要 属性，它们在 数据管理 和 查询 中起着重要作用。以下是它们之间的区别：

1. 主键（Primary Key）：主键 是 表 中的一个或多个 列 的组合，用于唯一标识 表 中的每一行 数据。主键 具有以下特点：

• 唯一性：主键值 在整个 表 中必须是唯一的，不允许重复。
• 非空性：主键列 不能包含空值（NULL）。
• 不可变性：一旦设定了 主键，就不能改变。
• 主键 可以是一个单独的 列，也可以是多个 列 的组合。

2. 外键（Foreign Key）：外键 是 表 中的一个或多个 列 的组合，用于与其他 表 建立 关联关系。外键 指向另一个 表 的 主键，表示该行 数据 与该 主键 相关联。外键 具有以下特点：

• 引用完整性：外键值 必须在被引用的 表 中存在，否则会导致 引用完整性错误。
• 可选性：外键列 可以包含空值（NULL），表示该行 数据 没有与任何 主键 相关联。
• 可变性：外键列 的值可以改变，但必须保证 引用完整性。

3. 索引（Index）：索引 是一种 数据结构，用于快速查找、插入和删除 数据库表 中的 数据。索引 可以创建在单个 列 或多个 列 上，以提高 查询性能 和 数据访问速度。索引 具有以下特点：

• 唯一性：索引值 在 索引列 中必须是唯一的，但允许在 表 中重复。
• 可选性：索引列 可以包含空值（NULL）。
• 可变性：索引列 的值可以改变，不会影响 索引 的使用。

可以看出，主键 和 外键 主要用于 表 之间的 关联 和 数据完整性约束，而 索引 主要用于提高 查询性能 和 数据访问速度。此外，主键 和 外键 都是 约束性 的，不能随意改变，而 索引 是 非约束性 的，可以根据需要进行创建和删除。

速记

数据库里有三宝，主键外键索引好。
主键唯一标识妙，非空不变很可靠，单列多列都能搞。
外键关联把线找，引用完整别乱跑，空值可变要确保。
索引查询速度高，唯一可选能改造，增删查改它领跑。
主外约束不能少，数据关联有依靠；索引非约性能好，按需创建随便搞。

5，Innodb为什么要用自增id作为主键？

InnoDB 使用 自增 ID 作为 主键 有以下几个原因：

1. 提高插入效率：在 InnoDB 中，使用 自增 ID 作为 主键 可以提供高效的 插入操作。当一条新的 记录 被插入到 表 中时，InnoDB 会为该 记录 分配一个新的 自增 ID，而不需要进行复杂的 主键冲突检测。这样可以避免由于 主键冲突 而导致的 插入失败 和 重试，提高了 插入操作 的 效率。
2. 提高查询效率：在 InnoDB 中，主键 被用作 索引 来加速 查询操作。使用 自增 ID 作为 主键 可以确保新插入的 记录 在 主键索引 中是 有序 的，这样在 查询 时可以更快地定位到目标 记录，提高了 查询 的 效率。
3. 避免页分裂：InnoDB 使用 B+ 树 作为 索引结构，数据 按照 主键 的顺序存储在 磁盘 上。如果使用 自增 ID 作为 主键，新的 记录 会被插入到当前 索引页 的末尾，这样可以避免 页分裂，减少 磁盘 IO 操作。如果使用 非自增 ID 作为 主键，可能会导致 页分裂，增加 磁盘 IO 操作，降低 性能。
4. 易于管理和维护：自增 ID 是按照 顺序 生成的，非常 直观 和 易于理解。在 数据备份 和 恢复 时，可以更方便地定位和管理 数据。此外，自增 ID 也可以方便地进行 分页查询 和 排序操作。

总之，使用 自增 ID 作为 主键 可以提高 数据库 的 性能 和 可维护性，因此在设计 数据库表 时，如果没有特别的需要，建议使用 自增 ID 作为 主键。

速记

InnoDB主键咋选好，自增ID有高招。
插入高效冲突少，无需检测速度跑。
查询加速定位妙，主键有序效率高。
页分裂也能避免，磁盘IO少烦恼。
管理维护真可靠，备份恢复很明了。
分页排序都易搞，性能维护呱呱叫。
若无特殊的需要，自增主键就选好。

6， 联合索引，覆盖索引，聚集索引与非聚集索引

联合索引、覆盖索引、聚集索引 和 非聚集索引 是 MySQL 中的几种常见 索引类型，它们在 数据管理 和 查询 中起着重要作用。以下是它们之间的区别：

1. 联合索引（Composite Index）：联合索引 是由多个 列 组成的 索引，可以用于 多列联合查询 和 排序操作。联合索引 可以提高 查询性能，但需要注意 列的顺序 和 选择性，以及避免 冗余索引 的问题。在使用 联合索引 时，应该尽量使 查询语句 中的 列 与 索引列 的顺序一致，以便充分利用 索引。
2. 覆盖索引（Covering Index）：覆盖索引 是指 查询语句 中所需的 数据 都可以从 索引 中获取，而不需要再 回表查询。这样可以避免对 表 的访问，提高 查询性能。在创建 覆盖索引 时，需要将 查询语句 中所需的 列 都包含在 索引 中。
3. 聚集索引（Clustered Index）：聚集索引 是按照 表 中 主键 的顺序存储 数据 的 索引。在 InnoDB 存储引擎 中，主键索引 就是 聚集索引。聚集索引 可以提高 查询性能，因为 数据 是按照 主键 的顺序存储的，可以更快地定位到目标 记录。此外，聚集索引 还可以减少 磁盘 IO 操作，因为相邻的 数据记录 存储在同一页中。聚簇索引 的 叶节点 就是 数据节点。每个 表 只能有一个 聚簇索引，因为 数据 在物理存储上只能按照一种顺序存放。使用 聚簇索引 时，数据 在磁盘上的 物理顺序 与 索引顺序 一致，因此 查询速度 快，效率 高。
4. 非聚集索引（Non-Clustered Index）：非聚集索引 是按照 表 中 非主键列 的顺序存储 数据 的 索引。在 InnoDB 存储引擎 中，除了 主键索引 外的其他 索引 都是 非聚集索引。非聚集索引 可以提高 查询性能，但因为 数据 不是按照 索引列 的顺序存储的，需要进行 回表查询 才能获取所需的 数据。此外，非聚集索引 还会占用更多的 存储空间，因为需要额外存储 索引列 的值和指向 数据记录 的 指针。非聚簇索引 的 叶节点 是 数据指针，指向对应の 数据节点。一个 表 可以有多个 非聚簇索引，因为 非聚簇索引 只是对 数据 的复制，并不改变 数据 的 物理存储顺序。使用 非聚簇索引 时，数据 在磁盘上的 物理顺序 与 索引顺序 不一致，因此 查询速度 相对较慢，需要先从 索引 中找到对应 数据 的 指针，然后再通过 指针 找到实际的 数据。

在选择 索引类型 时，需要根据 数据类型、查询需求 和 表的结构 进行综合考虑。合理的 索引策略 可以提高 查询性能 和 数据访问速度，而不合理的 索引策略 可能导致 性能下降 和 存储空间 的浪费。

速记

MySQL索引类型妙，联合覆盖聚非聚瞧。
联合索引多列搞，查询排序呱呱叫，列序选择别乱套，冗余索引要避掉。
覆盖索引真高效，索引数据全拿到，回表查询不用跑，性能提升没烦恼。
聚集索引主键靠，数据存储按序找，定位记录速度高，磁盘IO也减少，一表只能有一条，物理顺序它主导。
非聚索引非主搞，回表查询不可少，指针指向数据跑，空间占用有点糟，一表能有多条搞，物理顺序它不扰。
索引类型选得好，查询性能大提高，策略不当就拉倒，存储浪费不得了。

7， 说一说索引的实现原理

MyISAM 引擎 和 InnoDB 引擎 是 MySQL 中常用的两种 存储引擎，它们对于 索引 的 实现原理 有所不同。

MyISAM 引擎 使用的是 非聚集索引。在 MyISAM 中，索引文件 和 数据文件 是分离的，索引文件 仅保存 数据记录 的 地址。MyISAM 的 索引 采用 B+ 树 的 数据结构，叶节点 的 data 域 存放的是 数据记录 的 地址。MyISAM 的 主索引 和 辅助索引 在 结构 上没有任何区别，只是 主索引 要求 key 是唯一的，而 辅助索引 的 key 可以重复。辅助索引 一次检索就可找到 数据，主键索引 和 辅助索引 引用相同的 地址，都使用一个 地址 指向真正的 表数据。

相比之下，InnoDB 引擎 使用的是 聚集索引。在 InnoDB 中，表数据文件 本身就是按 主键 顺序存放的，因此 主键索引 的 查询 可以直接通过 数据文件 本身进行，这就是所谓的 聚集索引。InnoDB 的 辅助索引 与 MyISAM 的 辅助索引 有所不同，InnoDB 的 辅助索引 的 叶节点 并不包含 数据记录 的 地址，而是包含 主键 的值。当通过 辅助索引 查询时，InnoDB 首先找到 辅助索引 的 叶子节点，获取到对应的 主键值，然后再通过 主键值 查询到 数据记录 的 地址，从而获取到完整的 数据记录。

总的来说，MyISAM 和 InnoDB 在 索引实现 上的主要区别在于，MyISAM 的 主索引 和 辅助索引 没有实质区别，只是 主键索引 要求 key 唯一，辅助索引 的 key 可以重复；而 InnoDB 的 主键索引 是 聚集索引，数据文件 和 主键索引文件 是同一个文件，辅助索引 则包含 主键值，需要先查询到 主键值，再通过 主键值 查询到 数据记录 的 地址。

速记

MySQL引擎俩常用，MyISAM和InnoDB。
索引实现各不同，且听我来唠一唠。
MyISAM非聚集，索引数据两分离。
B+树里存地址，主副结构无差异。
主键唯一辅助可，一次检索数据齐。
InnoDB搞聚集，主键数据同一起。
辅助索引含主键，先找主键再寻迹。
MyISAM较统一，InnoDB分阶梯。
索引区别要牢记，选对引擎提效率。

8，B 树& B+树

B 树 和 B+ 树 都是常用的 数据结构，它们都被广泛应用于 数据库 和 文件系统 的 索引 中。它们之间有一些 共同点 和 不同点。

相同点：

1. B 树 和 B+ 树 都是 平衡多路查找树，具有相同的 查找、插入 和 删除操作。
2. B 树 和 B+ 树 的 节点 都包含 关键字 和指向 子节点 的 指针。
3. B 树 和 B+ 树 都满足 平衡二叉树 的特性，即任何一个 节点 的 左子树 和 右子树 的 高度差 不超过 1。

不同点：

1. B 树 的每个 节点 既包含 关键字，也包含指向 数据记录 的 指针，而 B+ 树 的 非叶子节点 只包含 关键字，不包含指向 数据记录 的 指针，数据记录 只保存在 叶子节点 中。
2. B+ 树 的 叶子节点 包含了 父节点 的所有 关键字记录 的 指针，而 B 树 的 叶子节点 并没有这样的 指针。
3. B+ 树 的 叶子节点 的 关键字 从小到大 有序排列，左边结尾 数据 都会保存右边 节点 开始 数据 的 指针，这样可以方便地进行 范围查询。而 B 树 则只能通过 中序遍历 进行 范围查询。
4. B+ 树 相对于 B 树 来说，层级 更少，每个 非叶子节点 存储的 关键字数 更多，因此 查询数据 更快。而且由于所有 关键字数据地址 都存在 叶子节点 上，所以每次 查找的次数 都相同，查询速度 更稳定。

总体来说，B+ 树 是 B 树 的一种 升级版本，在 性能 和 稳定性 方面比 B 树 更优秀。在 数据库 和 文件系统 的 索引 中，B+ 树 比 B 树 更常用。

速记

B树B+树，索引常用处。
平衡多路查，操作很相似。
节点含关键，指针也不迟。
平衡二叉性，高度差一致。

B树较特殊，数据指针附。
B+非叶处，只存关键字。
数据叶节点，排列有顺序。
范围查询妙，层级也更稀。

B+是升级，性能更优异。
索引常用它，优势很清晰。

9， MySQL的索引为什么用B+树？

MySQL 的索引使用 B+ 树 作为数据结构，主要有以下几个原因：

1. B+ 树 的 磁盘读写代价 相对较低。B+ 树 的 内部节点 并没有指向 关键字 具体信息的指针，这样 内部节点 相对 B 树 更小，如果把所有同一 内部节点 的 关键字 存放在同一 盘块 中，那么 盘块 所能容纳的 关键字 数量也越多，一次性读入 内存 的需要查找的 关键字 也就越多，相对来说 IO 读写次数 也就降低了。
2. B+ 树 的 查询效率 更加稳定。由于 非终结点 并不是最终指向 文件内容 的结点，而只是 叶子结点 中 关键字 的 索引。所以任何 关键字 的查找必须走一条从 根结点 到 叶子结点 的路。所有 关键字查询 的 路径长度 相同，导致每一个 数据 的 查询效率 相当。
3. B+ 树 便于进行 范围查询。B+ 树 的 叶子节点 使用 指针顺次连接，只要遍历 叶子节点 就可以实现整棵树的遍历。而且在 数据库 中基于 范围的查询 是非常频繁的，而 B 树 不支持这样的遍历。
4. B+ 树 是 B 树 的升级版，性能 更优秀。相对于 B 树 来说，B+ 树 的 层级 更少，每个 非叶子节点 存储的 关键字数 更多，因此 查询数据 更快。而且由于所有 关键字数据地址 都存在 叶子节点 上，所以每次 查找的次数 都相同，查询速度 更稳定。

综上所述，B+ 树 相比 B 树 更适合作为 MySQL 的 索引数据结构，因为它具有更低的 磁盘读写代价、更稳定的 查询效率、更方便的 范围查询 以及更优秀的 性能表现。

速记

MySQL用索引，B+树来助力。
磁盘读写低，节点无指针记。
盘块容量大，IO次数减下去。
查询稳无比，路径都统一。
根到叶子走，效率差不多齐。
范围查询妙，叶子连一起。
顺着指针找，B树比不起。
B+是升级，层级少且密。
关键字更多，性能数第一。
MySQL选它，优势很清晰。

10， MySQL的Hash索引和B树索引有什么区别？

参考答案

MySQL 的 Hash 索引和 B 树索引主要有以下几个区别：

1. 实现方式：hash 索引底层就是 hash 表，进行查找时，调用一次 hash 函数就可以获取到相应的键值，之后进行回表查询获得实际数据。B+ 树底层实现是多路平衡查找树，对于每一次的查询都是从根节点出发，查找到叶子节点方可以获得所查键值，然后根据查询判断是否需要回表查询数据。
2. 查询效率：对于等值查询，Hash 索引具有明显的优势，因为只需要经过一次哈希算法即可找到相应的键值；而B 树索引需要进行多次查找。但是，对于范围查询，B 树索引具有优势，使用索引进行排序，因为 B+ 树的叶子节点是顺序排列的，可以方便地进行范围查询，而 Hash 索引则无法支持范围查询。
3. 稳定性：B+ 树索引的关键字检索效率比较平均，而 Hash 索引的检索效率不稳定。在有大量重复键的情况下，Hash 索引的效率也是极低的，因为存在哈希碰撞问题。
4. 适用范围：Hash 索引只适用于等值查询，hash 索引不支持模糊查询以及多列索引的最左前缀匹配，而 B 树索引可以适用于等值查询和范围查询。此外，B 树索引可以支持联合索引的最左前缀匹配规则，而 Hash 索引则无法支持。
5. 维护和管理：B 树索引需要定期进行维护和优化，而 Hash 索引则不需要。但是，当数据库中的数据量非常大时，Hash 索引的维护成本可能会很高。

总的来说，Hash 索引和B 树索引各有优缺点，应根据具体情况选择合适的索引类型。对于等值查询，可以使用Hash 索引；对于范围查询和其他复杂的查询，可以使用B 树索引。

速记

MySQL俩索引，Hash和B树，听我来唠嗑，区别说一说。

实现各不同，Hash表底层，一次哈希行，回表把数寻。
B树多路查，根到叶子爬，键值拿到手，回表再研究。

查询看场景，等值Hash行，一次就搞定，速度超带劲。
范围找B树，叶子排得酷，范围随便查，Hash没法搭。

稳定有差异，B树较整齐，Hash不稳定，碰撞就发懵。
重复键太多，Hash就翻车。

适用有不同，Hash很集中，只做等值查，其他没办法。
B树功能全，等值范围兼，联合索引棒，最左能匹配。

维护不一样，B树要调养，Hash较清爽，量大也发慌。

索引咋来选，场景是关键，等值Hash炫，复杂B树赞。

11，如何创建及保存MySQL的索引？

在MySQL中，创建和保存索引可以通过以下步骤完成：

1. 打开MySQL客户端，并连接到相应的数据库。
2. 使用CREATE INDEX语句创建索引。语法如下：

CREATE [UNIQUE] INDEX index_name ON table_name (column1, column2, ...);

其中，index_name是索引的名称，table_name是表的名称，column1, column2, ...是要创建索引的列名。UNIQUE关键字可选，用于创建唯一索引。

例如，为名为users的表的email列创建一个非唯一索引，可以使用以下语句：

CREATE INDEX idx_email ON users (email);

3. MySQL将执行创建索引的操作，并在表中创建相应的索引。这个过程可能需要一些时间，具体取决于表的大小和复杂度。
4. 创建索引后，可以通过SHOW INDEXES语句查看表的索引信息。语法如下：

SHOW INDEXES FROM table_name;

例如，查看名为users的表的索引信息，可以使用以下语句：

SHOW INDEXES FROM users;

这将显示表的索引信息，包括索引名称、索引类型、索引列等。

请注意，创建索引后，对表进行写入操作时，性能可能会略有下降，因为每次写入操作都需要更新索引。但是，对于读取操作，使用索引可以大大提高查询效率。因此，需要根据具体情况权衡索引的利弊，并选择合适的索引类型。

12，MySQL怎么判断要不要加索引？

参考答案

在 MySQL 中，判断是否需要添加索引可以通过以下几个方面进行考虑：

1. 查询频率：如果某个查询在数据库中经常被执行，那么可以考虑为该查询涉及的列添加索引。通过索引可以加快查询速度，提高性能。
2. 查询条件：如果查询条件中经常涉及到某些列的比较操作，如 WHERE 子句中的等于、不等于、大于、小于等比较操作符，那么可以考虑为这些列添加索引。索引可以加快比较操作的速度，从而提高查询性能。
3. 数据重复性：如果某个列的数据在表中重复率很高，例如性别、地区等，那么为该列添加索引可能不太必要。因为索引的效果在数据重复率高的情况下会减弱，而且索引本身也会占用一定的存储空间和维护成本。
4. 表的大小：如果表中的数据量非常大，那么添加索引可能会带来一定的性能提升。但是，如果表很小，添加索引可能并不会带来明显的性能改善，反而会增加维护成本。
5. 索引的选择性：选择性是指某个索引能够唯一标识的数据行的比例。如果一个索引的选择性很高，意味着该索引能够很好地过滤数据，从而提高查询性能。可以通过计算索引的选择性来判断是否需要添加索引。

综上所述，判断是否需要添加索引需要根据具体情况进行综合考虑。可以通过分析查询语句、表结构和数据特征等方面来评估是否需要添加索引，以及选择何种类型的索引。

速记

MySQL里判索引，几个方面细分辨。
查询频率先来看，高频查询加索引，速度提升不一般。
查询条件是关键，比较操作常出现，相关列上加索引，性能提高很明显。
数据重复要留意，重复太高别着急，索引效果会降低，维护成本还不低。
表的大小也重要，大表加索性能好，小表加索没必要，维护成本反提高。
索引选择看比例，比例越高越给力，过滤数据有优势，查询性能创佳绩。
添加索引要综合，具体情况细琢磨，语句结构和数据，评估之后再定夺。

13，只要创建了索引，就一定会走索引吗？

参考答案

不一定。比如，在使用组合索引的时候，如果没有遵从“最左前缀”的原则进行搜索，则索引是不起作用的。举例，假设在 id、name、age 字段上已经成功建立了一个名为 MultiIdx 的组合索引。索引行中按 id、name、age 的顺序存放，索引可以搜索 id、（id, name）、（id, name, age）字段组合。如果列不构成索引最左面的前缀，那么 MySQL 不能使用局部索引，如（age）或者（name, age）组合则不能使用该索引查询。

速记

组合索引有说道，最左前缀很重要。
MultiIdx建得好，id、名、龄顺序找。
搜索要用左前缀，id单查也有效。
id、名搭配也能搞，三者齐全更可靠。
若不按此规则搞，像查age或名加龄，
索引失效白操劳，查询性能往下掉。

14，如何判断数据库的索引有没有生效？

参考答案

判断数据库索引是否生效可以通过以下几种方式：

1. 执行计划：使用 EXPLAIN 关键词来查看查询语句的执行计划。执行计划中会显示是否使用了索引，以及使用的索引类型等信息。如果执行计划中显示使用了索引，说明索引生效了。
2. 查询性能：比较查询语句在有索引和没有索引的情况下的性能表现。如果添加索引后，查询速度明显加快，说明索引生效了。
3. 索引统计信息：查看索引的统计信息，例如索引的使用次数、扫描行数等。如果索引的使用次数很高，扫描行数很少，说明索引生效了。
4. 慢查询日志：分析数据库的慢查询日志，查看是否有因为索引未生效而导致的慢查询。如果没有慢查询或者慢查询的数量明显减少，说明索引生效了。
5. 直接检查：直接检查数据库中的索引是否存在，以及是否正确设置了索引的列和类型等属性。可以通过 SHOW INDEXES 语句来查看表的索引信息。

需要注意的是，即使索引生效了，也并不一定能够完全满足查询的需求。有时候需要根据具体情况综合考虑，选择合适的索引类型和优化查询语句等方式来提高查询性能。

速记

索引生效咋判断，方法多样别犯难。
执行计划用 EXPLAIN ，显示索引就通关。
查询性能来对比，加速明显心不烦。
统计信息看一看，多用少扫才心安。
慢查日志细分析，没了慢查笑开颜。
直接检查别嫌烦， SHOW INDEXES 把卡翻。
生效未必都圆满，综合考量才周全。

15，如何评估一个索引创建的是否合理？

评估数据库索引创建是否合理可以通过以下几个方面：

1. 查询性能：添加索引后，查询语句的性能是否得到明显改善。可以通过比较添加索引前后的查询执行时间、扫描行数等指标来评估索引的效果。
2. 索引选择性：索引选择性是指索引列的唯一值与表中总行数的比例。高选择性的索引可以更好地过滤数据，从而提高查询性能。可以通过计算索引的选择性来评估索引的质量。
3. 索引覆盖度：索引覆盖度是指查询语句中需要访问的列是否都被索引所覆盖。如果查询语句中需要访问的列都被索引所覆盖，那么查询只需要访问索引，而不需要访问表，从而提高查询性能。可以通过分析查询语句和索引的列来确定索引的覆盖度。
4. 索引的使用频率：如果某个索引经常被使用，那么说明该索引是有价值的。可以通过查看索引的使用次数来评估索引的价值。
5. 索引维护成本：索引的维护成本包括创建索引、更新索引和删除索引等操作所需的时间和资源。如果索引的维护成本过高，那么可能会影响数据库的性能和可用性。可以通过分析索引的大小、更新频率等因素来评估索引的维护成本。
6. 表的更新频率：如果表经常被更新，那么添加索引可能会影响更新的性能。因为每次更新操作都需要更新相应的索引。可以通过分析表的更新频率来评估添加索引的影响。

综上所述，评估数据库索引创建是否合理需要从多个方面综合考虑。可以通过分析查询性能、索引选择性、索引覆盖度、索引使用频率、索引维护成本和表的更新频率等因素来评估索引的质量和价值。同时，也可以通过实际测试来验证索引的效果。

速记

索引创建咋评估，多个方面要关注。
查询性能先看住，前后对比时间数。
选择比例要适度，高选过滤不含糊。
覆盖列数要清楚，全盖索引少绕路。
使用频率不能忽，常用索引价值足。
维护成本细算数，太高性能会降速。
表的更新也得顾，频繁更新要兼顾。
综合考量才靠谱，实际测试来辅助。

16, 数据库索引失效了怎么办？

参考答案

数据库索引 失效了，可以考虑以下几种解决方式：

1. 优化查询语句：通过对 查询语句 进行优化，尽量让其能够走 索引。例如，可以通过调整 WHERE 子句 中的条件顺序，让其先过滤掉大部分 数据，再使用 索引 进行精确匹配。
2. 新建索引：根据 查询语句 的需求，新建合适的 索引。在选择 索引列 时，需要考虑 选择性、覆盖度 等因素，以及避免在 WHERE 子句 中使用 <>、!= 等操作符。
3. 分析索引统计信息：通过分析 索引 的 统计信息，找出 索引 失效的原因。例如，查看 索引 的使用次数、扫描行数等指标，判断 索引 是否合理选择。
4. 考虑使用联合索引：联合索引 可以同时覆盖多个 列，提高 查询性能。在创建 联合索引 时，需要考虑 查询语句 中的条件顺序，以及避免在 WHERE 子句 中使用 <>、!= 等操作符。
5. 考虑使用全文索引：对于需要进行 全文搜索 的场景，可以考虑使用 全文索引。全文索引 可以对 文本内容 进行 分词、去重 等操作，提高 查询性能。
6. 调整数据库参数：有时候，数据库 的一些 参数设置 可能会影响 索引 的效果。例如，MySQL 的 innodb_buffer_pool_size 参数 会影响 InnoDB 存储引擎 的 缓存大小，如果设置不合理，可能会导致 索引 失效。可以通过调整这些 参数 来优化 数据库性能。

综上所述，数据库索引 失效了需要从多个方面综合考虑，找出失效的原因，并选择合适的解决方式。可以通过 优化查询语句、新建索引、分析索引统计信息、考虑使用联合索引、考虑使用全文索引 以及 调整数据库参数 等方式来解决问题。同时，也需要注意在日常维护中定期对 数据库 进行 优化 和 监控，及时发现和解决问题。

速记

索引失效别慌张，几种方法来帮忙。
查询语句先优化，条件顺序细排查。
新建索引看需求，选择覆盖要兼顾。
统计信息分析透，使用扫描指标瞅。
联合索引威力强，条件顺序别乱尝。
全文搜索场景棒，分词去重性能涨。
参数设置要妥当，引擎缓存莫乱闯。

17，所有的字段都适合创建索引吗？

参考答案

数据库 中并不是所有 字段 都适合创建 索引。虽然 索引 可以提高 查询性能，但也会带来一些负面影响，如占用 磁盘空间、降低 写入性能 等。因此，在创建 索引 时需要综合考虑多个因素，如 查询频率、数据重复性、表的大小 等。

一般来说，以下 字段 适合创建 索引：

1. 主键 和 外键字段：主键 和 外键字段 是表的关键字段，必须在 查询 中使用，因此适合创建 索引。
2. 频繁作为查询条件的字段：如果某个 字段 在 查询 中经常被用作条件，那么适合为该 字段 创建 索引。
3. 高选择性的字段：高选择性的字段 可以更好地过滤 数据，从而提高 查询性能。
4. 小数据量的字段：对于 小数据量的字段，创建 索引 带来的 性能提升 可能更加明显。

然而，以下 字段 不适合创建 索引：

1. 频繁更新的字段：如果某个 字段 经常被更新，那么创建 索引 会降低 写入性能。
2. 重复率高的字段：对于 重复率高的字段，创建 索引 的效果可能不太明显。
3. 大数据量的字段：对于 大数据量的字段，创建 索引 会占用大量的 磁盘空间，并降低 查询性能。
4. 文本字段：对于 文本字段，创建 索引 的效果可能不太明显，而且会带来更高的 维护成本。

综上所述，在创建 索引 时需要综合考虑多个因素，选择合适的 字段 进行 索引。同时，也需要注意在日常维护中定期对 数据库 进行 优化 和 监控，及时发现和解决问题。

速记

索引并非全适合，正负影响要权衡。
盘占写降是弊端，多因考量才可行。
适合索引有几类，主键外键不能废。
查询条件常用处，高选小量也般配。
更新频繁要避讳，重复量大效果微。
数据庞大占空间，文本字段也吃亏。
创建索引细分辨，合理使用性能添。

18，介绍一下数据库索引的重构过程

参考答案

什么时候需要 重建索引 呢？

表上频繁发生 update, delete 操作；

表上发生了 alter table ..move 操作（move 操作导致了 rowid 变化）。

如何 重建索引？

（1）drop 原索引，然后再创建索引：

drop index index_name;

create index index_name on table_name (index_column);

（2）直接 重建索引：

alter index indexname rebuild;

alter index indexname rebuild online;

此方法较快，建议使用。

rebuild 是快速重建索引的一种有效的办法，因为它是一种使用现有索引项来重建新索引的方法。

速记

表上操作若频繁，增删修改或移迁。
索引失效不用烦，重建方法记心间。
方法一用先删添，先丢旧索再创建。 drop 之后 create 连，表列索引别弄反。
方法二是直接建， alter 命令来救援。 rebuild 跟上 online 添，此招快速又保险。
现有索引来重建，高效办法不一般。