Mysql常见八股文

1.了解索引吗？（什么是索引）

可以把索引理解成 MySQL 表的‘目录’—— 就像看书时查目录能快速找到章节，索引能让数据库不用逐行扫描全表，直接定位到要查的数据，核心是‘用空间换时间’。
关键有三点：

1. 本质是数据结构，MySQL 里最常用的是 B + 树（InnoDB 默认），通过层级结构按顺序存索引列的值，查的时候能快速跳级定位；
2. 作用是加速查询，比如查‘where id=100’，有索引直接找，没索引得扫整个表，效率差很多；
3. 有代价：会占额外存储，而且插入 / 更新 / 删除时要同步维护索引（比如调整 B + 树），会减慢写操作，所以不是索引越多越好，得按需建。

2.索引的数据结构有了解过吗？

B+树， 选择B+树的主要原因是 B+树有更多的子节点，路径更短，还有非叶子节点只存键值和指针，叶子节点存数据

3.什么情况会造成索引失效？

• sql语句 使用or来连接的语句， 比如 A or B，A有索引，B没有索引，整体只能全表扫描，造成索引失效
• 最左匹配原则， 比如有ABC联合索引， 你只能查 AB 或者 ABC，要是BC的话就会造成索引失效
• where关键字，查询语句里面where关键字后面进行函数运算，也会造成索引失效

4.怎么定位慢查询？

mysql本身提供慢查询日志功能，可以在mysql中的系统配置文件中开启这个慢查询，并设置sql执行多少时间就会记录到日志文件，比如我们设置的是2秒，超过2秒的sql就会存在日志中，我们可以从那里找到执行慢的sql

5.Sql语句执行很慢，怎么分析？

执行EXPLAIN + 慢SQL，通过输出的执行计划（重点看type、key、rows、Extra字段），判断 SQL 的执行逻辑是否合理。

• type：表示连接类型，反映查询效率。
  差的情况：ALL（全表扫描，必须优化）、index（全索引扫描，比 ALL 稍好，但仍需扫描整个索引）；
  好的情况：range（范围查询，如where id > 100）、ref（非唯一索引匹配）、eq_ref（主键 / 唯一索引匹配）、const（常量匹配，如where id=1）。
  → 若type是ALL或index，说明没用到有效索引，大概率是慢查询的主因。
• key：表示实际使用的索引。
  若key为NULL，说明没用到任何索引，需检查 “是否缺少索引” 或 “索引失效”。
• rows：预估需要扫描的行数（非精确值）。
  → 数值越大，查询效率越低（比如 100 万行，明显比 100 行慢）。
• Extra：额外信息，常出现的 “坑”：
  Using filesort：需要在内存 / 磁盘中排序（未用索引排序），耗时；
  Using temporary：需要创建临时表（如group by未用索引），耗时；
  Using where; Using index：覆盖索引（仅用索引就能返回结果，高效，没问题）；
  Using where; Using filesort：用了 where 过滤，但排序未用索引，需优化。

6.数据库事务：

数据库事务transaction正确执行的四个基本要素。ACID,原子性（Atomicity）、一致性（Correspondence）、隔离性（Isolation）、持久性（Durability）。

• 原子性：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
• 一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
• 隔离性： 并发执行的多个事务之间要“互不干扰”，仿佛各自在独立运行。如果没有隔离性就有可能出现脏读 不可重复读 幻读等问题
• 持久性：在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

7.数据库范式：

一：原子性 每一列不可拆分
二：必须有主键 每张表只描述一件事 其他列都依赖主键
三：任何非主键之间不依赖