1、三大范式
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式
第一范式：数据库表中不能出现重复记录，每个字段是原子性的不能再分。
关于第一范式，每一行必须唯一，也就是每个表必须有主键，这是我们数据库设计的最基本要求
第二范式：第二范式是建立在第一范式基础上的，另外要求所有非主键字段完全依赖主键，不能产生部分依赖。
第三范式：建立在第二范式基础上的，非主键字段不能传递依赖于主键字段。（不要产生传递依赖）
2、存储引擎以及各自的优缺点
- InnoDB引擎
InnoDB是MySQL 5.1之后默认的存储引擎，它支持事务、支持外键、支持崩溃修复和自增列。如果对业务的完整性要求较高，比如张三给李四转账，需要减张三的钱，同时给李四加钱，这时候只能全部执行成功或全部执行失败，此时可以通过InnoDB来控制事务的提交和回滚，从而保证业务的完整性。
优缺点：
1.InnoDB的优势是支持事务、支持外键、支持崩溃修复和自增列。
2.它的缺点是读写效率较差、占用的数据空间较大。 - MyISAM引擎
MyISAM是MySQL 5.1之前默认的数据库引擎，读取效率较高，占用数据空间较少，但不支持事务、不支持行级锁、不支持外键等特性。因为不支持行级锁，因此在添加和修改操作时，会执行锁表操作，所以它的写入效率较低。
优缺点：
MyISAM引擎保存了单独的索引文件.myi，且它的索引是直接定位到 OFFSET 的，而InnoDB没有单独的物理索引存储文件，且InnoDB索引寻址是先定位到块数据，再定位到行数据，所以MyISAM的查询效率是比InnoDB的查询效率要高。但它不支持事务、不支持外键，所以它的适用场景是读多写少，且对完整性要求不高的业务场景。 - MEMORY存储引擎
内存型数据库引擎，所有的数据都存储在内存中，因此它的读写效率很高，但MySQL服务重启之后数据会丢失。它同样不支持事务、不支持外键。MEMORY 支持 Hash 索引或 B 树索引，其中 Hash 索引是基于 key 查询的，因此查询效率特别高，但如果是基于范围查询的效率就比较低了。而前面两种存储引擎是基于 B+ 树的数据结构实现了。
优缺点：
MEMORY 读写性能很高，但MySQL服务重启之后数据会丢失，它不支持事务和外键。适用场景是读写效率要求高，但对数据丢失不敏感的业务场景。 - BerkeleyDB简称BDB
支持事务，而且支持mvcc的行级锁，主要用于日志记录或同步归档，这个存储引擎除非有特别目的，否则不适合使用！ - 总结
MySQL中最常见的存储引擎有：InnoDB、MyISAM和 MEMORY，其中InnoDB是MySQL 5.1之后默认的存储引擎，它支持事务、支持外键、支持崩溃修复和自增列，它的特点是稳定（能保证业务的完整性），但数据的读写效率一般；而MyISAM的查询效率较高，但不支持事务和外键；MEMORY 的读写效率最高，但因为数据都保存在内存中的，所以MySQL服务重启之后数据就会丢失，因此它只适用于数据丢失不敏感的业务场景。
3、事务隔离级别
定义了四种事务隔离界别，分别是
- 读未提交（Read Uncommitted）
- 读已提交（Read Committed）
- 可重复读（Repeatable Read）(默认情况使用)
- 串行化（Serializable）
不同的隔离级别下会产生脏读、幻读、不可重复读等相关问题，因此在选择隔离级别的时候要根据应用场景来决定，使用合适的隔离级别。
各种隔离级别和数据库事务并发时存在的问题对应情况如下：
1)读未提交（Read Uncommitted）允许脏读，就是在该隔离级别下，可能读到其他会话未提交事务修改的数据，存在脏读、不可重读读、幻读的问题。
2)读已提交（Read Committed）只能查询到已提交的数据。这是 Oracle 数据库默认的事务隔离级别。存在可重读读、幻读的问题。
3)可重复读（Repeatable Read）就是在一个事务里相同条件下，无论何时查到的数据都和第一次查到的数据一致。这是 MySQL 数据库InnoDB 引擎默认的事务隔离级别。在范围查询时存在幻读的问题。
4)串行化（Serializable）是最高的事务隔离级别，它严格服从 ACID 特性的隔离级别。所有的事务依次逐个执行，事务之间互不干扰，该级别可以防止脏读、不可重复读以及幻读。但每个事务读数据时都需要获取表级的共享锁，导致读和写都会阻塞，性能极低。
方便记
脏读：读到了其他事务未提交的数据
不可重复读：同一事务内，两次读取同一行数据结果不一致
幻读：同一事务内，两次查询行数变多或变少
读未提交：三种问题都存在
读已提交：解决脏读
可重复读：解决脏读 + 不可重复读（MySQL 默认）
串行化：全部解决，但性能极差，一般不用
其他
横表
- 特点
1)同一个Key值对应的列是固定的，比如，比如HorizontalTable中有6个字段
2)各个字段的值是自由的，比如HorizontalTable中的CategoryVal1是varchar类型的，CategoryVal2是decimal的
3)表中并不存储描述性字段本身（相比纵表）
4)相比竖表，存储同样多的数据，行数要少 - 优点
横标的有点事显示的较为清晰直观，同时在字段的选择上更为科学合理，具体的字段可以根据具体情况划分字段类型 - 缺点
不方便扩展和公用，也就是说设计了一张横标，只能在固定的某一种特定的相对不变的场景下使用，比如加字段，或者类似的业务想公用一张横表，都有局限
竖表
- 特点
1)同一个Key值对应的列是动态的，因为是按照行存储的，可以存储成Key1—Value1，Key1—Value2，Key1—Value3的方式存储
2)字段的类型是固定的,但是类似是要兼容的，不能有个性化的字段，比如VerticalTable中的CategoryKey+Val，因为固定了这么一个字段
3)表中需要存储描述字段本身（相比横标），要根据BusinessKey值的不同，重复存储CategoryKey
4)相比横表，存储同样多的数据，行数要多 - 优点
最大的特点是可以灵活扩展存储的内容，同时具有一定的公用性
因为竖表的存储结构不受字段个数的限制，可以存储具有一定共性的业务数据。 - 缺点
竖表的字段类型要兼容，比如横标可以根据具体的值设计成varchar，decimal，datetime等，横表为了兼容以上字段类型，只能设计成varchar的，可能会浪费一定的空间。
4、索引
1.InnoDB 索引默认是什么数据结构？为什么？
InnoDB 索引默认使用 B+ 树 作为底层数据结构，原因如下：
多路平衡设计，树高极低：B+ 树是多路平衡查找树，非叶子节点只存索引键（不存完整数据），单个节点（16KB 页）可存储上千个 key，千万 / 亿级数据树高仅 3-4 层，查询时磁盘 I/O 次数极少，性能极高。
叶子节点双向有序链表：所有叶子节点用双向链表串联，全局有序，完美支持范围查询、排序、分组操作。
查询性能稳定：所有查询都必须从根节点走到叶子节点，I/O 次数稳定，无性能波动。
对比其他结构优势明显：比二叉树 / 红黑树树高更低、比哈希表支持范围查询、比 B 树非叶子节点不存数据，树高更低、范围查询效率更高。
2.什么是聚簇索引、二级索引？区别是什么？
聚簇索引（主键索引）：叶子节点直接存储整行完整数据，一个表只有 1 个聚簇索引，默认由主键构建。
二级索引（非聚簇索引）：叶子节点存储索引列 key + 主键值，不存完整数据。
核心区别：
存储内容不同：聚簇索引存整行数据，二级索引存主键；
数量不同：一个表只有 1 个聚簇索引，可建多个二级索引；
查询流程不同：二级索引查询需要回表（先查二级索引拿主键，再查聚簇索引拿完整数据），聚簇索引直接查询无需回表。
3.最左匹配原则是什么？
最左匹配原则是联合索引的核心规则：联合索引 (a,b,c) 中，查询必须从最左侧的字段开始匹配，不能跳过中间字段，否则索引失效。
4.哪些情况会导致索引失效？（至少说 3 个）
在 where 条件的索引字段上使用函数 / 运算（如 date(create_time) = ?）；
违反最左匹配原则（联合索引跳过左字段）；
like 以 % 开头（如 like '%abc'，% 结尾可命中）；
隐式类型转换（字符串字段用数字查询）；
使用！=、not in、is not null 等负向查询（部分场景会导致全表扫描）；
优化器认为全表扫描更快（数据量极小的表）。
5.什么是回表？什么是覆盖索引？
回表：二级索引查询时，先在二级索引树中查到主键值，再拿着主键去聚簇索引树中查询完整数据的过程。
覆盖索引：查询的字段全部包含在索引中，无需回表，直接从索引中获取数据，大幅提升查询效率。
例：索引 (name, age)，select name, age from user where name='xx' 就是覆盖索引。
6.简单说几条 MySQL 优化经验。
每张表必须设置主键，推荐用自增主键（避免 B+ 树页分裂）；
为频繁查询、排序、分组的字段建立索引，优先建联合索引；
避免 select *，只查需要的字段，尽量使用覆盖索引；
避免 like '%xxx' 开头的模糊查询，无法命中索引；
大表分页优化：不用 limit 100000,10，用延迟关联（where id > 100000 limit 10）；
避免在索引字段上使用函数、运算，防止索引失效；
合理设置事务隔离级别，避免长事务占用锁。
5、EXPLAIN 执行计划 + 慢查询优化
1.EXPLAIN 是干嘛的？
查看sql执行计划
判断索引有没有命中，sql走没走最优路径
定位慢 SQL 根源
EXPLAIN SELECT * FROM user WHERE id = 1;
2.type 从优到劣说出 4 个常见值
constref rangeindexall
const：根据主键 / 唯一索引等值查询，最快
ref：普通索引等值匹配
range：范围查询（between、in、> <）
index：遍历索引树
ALL：全表扫描（最差，要优化）
3.key 为 NULL 代表什么？
表示sql没有命中索引，走的全表查询
4.Extra 出现 Using filesort / Using temporary 代表什么？
filesort：出现文件排序，MySQL 无法用索引排序，必须优化
temporary：用到了临时表，一般是 group by /order by 不合理，必须优化
5.慢查询优化通用套路
先用 EXPLAIN 看有没有走索引
没有走索引建索引，优化语句避免索引失效
走了索引但依然慢：
看是否回表太多 → 用覆盖索引
看是否 filesort → 优化 order by
大分页优化：延迟关联、主键过滤
6.说出 3 个索引失效场景
使用 函数 操作索引列：where func(id)=1
隐式类型转换：varchar 字段用数字查
!= / <> / is not null / not in
like 以 % 开头：like '%abc'
违反最左匹配原则
6、MVCC
1.什么是 MVCC？
多版本并发控制，让读不加锁、读写不冲突，提高并发。
2.依赖三个核心东西
隐藏字段：trx_id（事务 ID）、roll_pointer（回滚指针）
undo log：历史版本链
ReadView：当前事务的 “可见性判断”
3.锁简单分类
共享锁 S：读锁，兼容，互斥写
排他锁 X：写锁，互斥所有
表锁：锁全表，并发低
行锁：锁行，并发高
间隙锁：锁住范围，防止幻读