索引是不是建的越多越好呢？
索引是不是建的越多越好呢？当然不是。索引会占据磁盘空间：每个索引都需要存储相应的数据结构和索引值，因此会占用一定的磁盘空间。随着索引数量和大小的增加，数据库的整体存储空间也会增加。
索引不适合哪些场景呢？
索引不适合哪些场景呢？有一些情况下，索引可能不适合使用，包括：数据量较少的表：对于数据量较少的表，索引的维护成本可能会超过索引本身带来的查询性能提升。在这种情况下，添加索引可能不划算。
索引哪些情况下会失效呢？
索引哪些情况下会失效呢？使用OR条件可能导致索引失效。当查询条件中包含OR操作符时，MySQL可能无法有效使用索引来加速查询，特别是如果OR操作符连接的条件列没有建立合适的索引。
创建索引有哪些注意点？
创建索引有哪些注意点？虽然索引是SQL性能优化的有力工具，但创建索引也需要考虑成本。因此，在创建索引时需要注意以下几点：
为什么使用索引会加快查询？
为什么使用索引会加快查询？在传统的查询方法中，MySQL会按照表的顺序逐行遍历数据，无论查询多少条数据，都需要将整个表的数据逐个比对。这种方法效率较低。
能简单说一下索引的分类吗？
能简单说一下索引的分类吗？从三个不同维度对索引分类：基于基本使用的角度，可以将上述内容改写如下：主键索引：在 InnoDB 存储引擎中，默认为每个表设置的索引，用于唯一标识每一行数据，不允许重复值和 NULL 值。每个表只能有一个主键索引。唯一索引：用于确保数据列的唯一性，不允许重复值，但允许 NULL 值。一个表可以创建多个唯一索引，可以针对多个列进行创建。
怎么看执行计划（explain），如何理解其中各个字段的含义？
怎么看执行计划（explain），如何理解其中各个字段的含义？explain 是 sql 优化的利器，除了优化慢 sql，平时的 sql 编写，也应该先 explain，查看一下执行计划，看看是否还有优化的空间。
有哪些方式优化慢 SQL？
有哪些方式优化慢 SQL？针对慢 SQL 查询的优化，可以从两个方面入手：SQL 语句本身的优化和数据库设计的优化。避免不必要的列避免查询不需要的列是一个常见的优化策略。在编写 SQL 查询时，应仅查询所需的列，而不是包含额外的列。尽量避免使用类似于 SELECT * 的写法。
慢 SQL 如何定位呢？
慢 SQL 如何定位呢？监控慢 SQL 的方法主要有两种途径：慢查询日志：通过启用MySQL的慢查询日志，并使用工具如mysqldumpslow来分析相应的慢查询日志。现在大多数云服务提供商也提供了可视化的平台来进行慢查询日志的分析和监控。
redo log 怎么刷入磁盘的知道吗？
redo log 怎么刷入磁盘的知道吗？redo log的写入并不直接写入磁盘，而是在内存中有一个称为"redo log buffer"的连续内存空间，也就是"重做日志缓冲区"。
