1、谈谈数据库设计的三大范式及反范式
（1）数据库的三大范式
第一范式：列不可分
第二范式：要有主键
第三范式：不可存在传递依赖
比如商品表里面关联商品类别表，那么只需要一个关联字段product_type_id即可，其他字段信息可以通过表关联查询即可得到 如果商品表还存在一个商品类别名称字段，如product_type_name，那就属于存在传递依赖的情况，第三范式主要是从空间的角度来考虑，避免产生冗余信息，浪费磁盘空间
（2）反范式设计：(第三范式) 为什么会有反范式设计？
原因一：提高查询效率（读多写少） 比如上述的描述中，显示商品信息时，经常需要伴随商品类别信息的展示， 所以这个时候，为了提高查询效率，可以通过冗余一个商品名称字段，这个可以将原先的表关联查询转换为单表查询
原因二：保存历史快照信息 比如订单表，里面需要包含收货人的各项信息，如姓名，电话，地址等等，这些都属于历史快照，需要冗余保存起来， 不能通过保存用户地址ID去关联查询，因为用户的收货人信息可能会在后期发生变更
2、drop、delete 与 truncate 区别？
drop(丢弃数据): drop table 表名 ，直接将表都删除掉，在删除表的时候使用。
truncate (清空数据) : truncate table 表名 ，只删除表中的数据，再插入数据的时候自增长 id 又从 1 开始，在清空表中数据的时候使用。
delete（删除数据） : delete from 表名 where 列名=值，删除某一行的数据，如果不加 where 子句和truncate table 表名作用类似。
truncate 和不带 where``子句的 delete、以及 drop 都会删除表内的数据，但是 truncate 和 delete 只删除数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也就是执行 drop 之后对应的表不复存在。
3、DML 语句和 DDL 语句区别：
（1）DML 是数据库操作语言（Data Manipulation Language）的缩写，是指对数据库中表记录的操作，主要包括表记录的插入、更新、删除和查询，是开发人员日常使用最频繁的操作。
（2）DDL （Data Definition Language）是数据定义语言的缩写，简单来说，就是对数据库内部的对象进行创建、删除、修改的操作语言。它和 DML 语言的最大区别是 DML 只是对表内部数据的操作，而不涉及到表的定义、结构的修改，更不会涉及到其他对象。DDL语句更多的被数据库管理员（DBA）所使用，一般的开发人员很少使用。
另外，由于select不会对表进行破坏，所以有的地方也会把select单独区分开叫做数据库查询语言 DQL（Data Query Language）。
4、MySQL 优点：
（1）成熟稳定，功能完善。
（2）开源免费。
（3）文档丰富，既有详细的官方文档，又有非常多优质文章可供参考学习。
（4）开箱即用，操作简单，维护成本低。
（5）兼容性好，支持常见的操作系统，支持多种开发语言。
（6）社区活跃，生态完善。
（7）事务支持优秀， InnoDB 存储引擎默认使用 REPEATABLE-READ 并不会有任何性能损失，并且，InnoDB 实现的 REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的。
（8）支持分库分表、读写分离、高可用。
5、一个 SQL 语句在 MySQL 中的执行流程
MySQL 主要由下面几部分构成
- （1）连接器： 身份认证和权限相关(登录 MySQL 的时候)。
- （2）查询缓存： 执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。
- （3）分析器： 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。
- （4）优化器： 按照 MySQL 认为最优的方案去执行。
- （5）执行器： 执行语句，然后从存储引擎返回数据。 执行语句之前会先判断是否有权限，如果没有权限的话，就会报错。
- （6）插件式存储引擎 ： 主要负责数据的存储和读取，采用的是插件式架构，支持 InnoDB、MyISAM、Memory 等多种存储引擎。MySQL 5.5.5 之前，MyISAM 是 MySQL 的默认存储引擎。5.5.5 版本之后，InnoDB 是 MySQL 的默认存储引擎。
MySQL 主要分为 Server 层和存储引擎层：
- （1）Server 层：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binlog 日志模块。
- （2）存储引擎： 主要负责数据的存储和读取，采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎，其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5 版本开始就被当做默认存储引擎了。
6、MySQL 存储引擎架构了解吗？
MySQL 存储引擎采用的是插件式架构，支持多种存储引擎，我们甚至可以为不同的数据库表设置不同的存储引擎以适应不同场景的需要。存储引擎是基于表的，而不是数据库。 并且，你还可以根据 MySQL定义的存储引擎实现标准接口来编写一个属于自己的存储引擎。这些非官方提供的存储引擎可以称为第三方存储引擎，区别于官方存储引擎。像目前最常用的 InnoDB 其实刚开始就是一个第三方存储引擎，后面由于过于优秀，其被 Oracle 直接收购了。
7、MyISAM 、InnoDB
（1）是否支持行级锁 MyISAM 只有表级锁(table-level locking)，而 InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。也就说，MyISAM 一锁就是锁住了整张表，这在并发写的情况下是多么滴憨憨啊！这也是为什么 InnoDB 在并发写的时候，性能更牛皮了！
（2）是否支持事务 MyISAM 不提供事务支持。InnoDB 提供事务支持，实现了 SQL 标准定义了四个隔离级别，具有提交(commit)和回滚(rollback)事务的能力。并且，InnoDB 默认使用的 REPEATABLE-READ（可重读）隔离级别是可以解决幻读问题发生的（基于 MVCC 和 Next-Key Lock）。
（3）是否支持外键 MyISAM 不支持，而InnoDB支持。外键对于维护数据一致性非常有帮助，但是对性能有一定的损耗。因此，通常情况下，我们是不建议在实际生产项目中使用外键的，在业务代码中进行约束即可！
（4）是否支持数据库异常崩溃后的安全恢复 MyISAM 不支持，而 InnoDB 支持。使用 InnoDB 的数据库在异常崩溃后，数据库重新启动的时候会保证数据库恢复到崩溃前的状态。这个恢复的过程依赖于 redo log 。
（5）是否支持 MVCC MyISAM 不支持，而 InnoDB 支持。讲真，这个对比有点废话，毕竟 MyISAM 连行级锁都不支持。MVCC 可以看作是行级锁的一个升级，可以有效减少加锁操作，提高性能。
（6）索引实现不一样。 虽然 MyISAM 引擎和 InnoDB 引擎都是使用 B+Tree 作为索引结构，但是两者的实现方式不太一样。InnoDB 引擎中，其数据文件本身就是索引文件。相比 MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按 B+Tree 组织的一个索引结构，树的叶节点 data 域保存了完整的数据记录。
（7）性能有差别。 InnoDB 的性能比 MyISAM 更强大，不管是在读写混合模式下还是只读模式下，随着 CPU 核数的增加，InnoDB 的读写能力呈线性增长。MyISAM 因为读写不能并发，它的处理能力跟核数没关系。
8、何谓数据库事务？
大多数情况下，我们在谈论事务的时候，如果没有特指分布式事务，往往指的就是数据库事务。 关系型数据库（例如：MySQL、SQL Server、Oracle 等）事务都有 ACID 特性：
原子性（Atomicity） ： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
一致性（Consistency）： 执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；
隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
🌈 这里要额外补充一点：只有保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。也就是说 A、I、D 是手段，C 是目的！
9、并发事务带来了哪些问题?
（1）脏读（Dirty read）一个事务读取数据并且对数据进行了修改，这个修改对其他事务来说是可见的，即使当前事务没有提交。这时另外一个事务读取了这个还未提交的数据，但第一个事务突然回滚，导致数据并没有被提交到数据库，那第二个事务读取到的就是脏数据，这也就是脏读的由来。
（2）丢失修改（Lost to modify）在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。
（3）不可重复读（Unrepeatable read）指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
（4）幻读（Phantom read）幻读与不可重复读类似。它发生在一个事务读取了几行数据，接着另一个并发事务插入了一些数据时。在随后的查询中，第一个事务就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。
10、并发事务的控制方式有哪些？
MySQL 中并发事务的控制方式无非就两种：锁 和 MVCC。 锁可以看作是悲观控制的模式， 多版本并发控制（MVCC，Multiversion concurrency control）可以看作是乐观控制的模式。
（1）锁 控制方式下会通过锁来显示控制共享资源而不是通过调度手段，MySQL 中主要是通过 读写锁 来实现并发控制。
1）共享锁（S 锁） ：又称读锁，事务在读取记录的时候获取共享锁，允许多个事务同时获取（锁兼容）。
2）排他锁（X 锁） ：又称写锁/独占锁，事务在修改记录的时候获取排他锁，不允许多个事务同时获取。如果一个记录已经被加了排他锁，那其他事务不能再对这条事务加任何类型的锁（锁不兼容）。
不论是表级锁还是行级锁，都存在共享锁（Share Lock，S 锁）和排他锁（Exclusive Lock，X 锁）这两类。
（2）MVCC 是多版本并发控制方法，即对一份数据会存储多个版本，通过事务的可见性来保证事务能看到自己应该看到的版本。通常会有一个全局的版本分配器来为每一行数据设置版本号，版本号是唯一的。在 MySQL 中实现所依赖的手段主要是: 隐藏字段、read view、undo log。undo log : undo log 用于记录某行数据的多个版本的数据。read view 和 隐藏字段 : 用来判断当前版本数据的可见性。
11、SQL 标准定义了哪些事务隔离级别?
（1）READ-UNCOMMITTED(读取未提交) ： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
（2）READ-COMMITTED(读取已提交) ： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
（3）REPEATABLE-READ(可重复读 MySQL 的默认隔离级别) ： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
（4）SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
InnoDB 实现的 REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的，主要有下面两种情况：
快照读 ：由 MVCC 机制来保证不出现幻读。
当前读 ： 使用 Next-Key Lock 进行加锁来保证不出现幻读，Next-Key Lock 是行锁（Record Lock）和间隙锁（Gap Lock）的结合，行锁只能锁住已经存在的行，为了避免插入新行，需要依赖间隙锁。
12、MySQL 的隔离级别是基于锁实现的吗？
MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。SERIALIZABLE 隔离级别是通过锁来实现的，READ-COMMITTED 和 REPEATABLE-READ 隔离级别是基于 MVCC 实现的。不过，SERIALIZABLE 之外的其他隔离级别可能也需要用到锁机制，就比如 REPEATABLE-READ 在当前读情况下需要使用加锁读来保证不会出现幻读。
13、行级锁的使用有什么注意事项？
InnoDB 的行锁是针对索引字段加的锁，表级锁是针对非索引字段加的锁。当我们执行 UPDATE、DELETE 语句时，如果 WHERE条件中字段没有命中唯一索引或者索引失效的话，就会导致扫描全表对表中的所有行记录进行加锁。这个在我们日常工作开发中经常会遇到，一定要多多注意！！！ 不过，很多时候即使用了索引也有可能会走全表扫描，这是因为 MySQL 优化器的原因。
14、InnoDB 有哪几类行锁？
InnoDB 行锁是通过对索引数据页上的记录加锁实现的，MySQL InnoDB 支持三种行锁定方式：
（1）记录锁（Record Lock） ：也被称为记录锁，属于单个行记录上的锁。
（2）间隙锁（Gap Lock） ：锁定一个范围，不包括记录本身。
（3）临键锁（Next-Key Lock） ：Record Lock+GapLock，锁定一个范围，包含记录本身，主要目的是为了解决幻读问题（MySQL事务部分提到过）。记录锁只能锁住已经存在的记录，为了避免插入新记录，需要依赖间隙锁。
在 InnoDB 默认的隔离级别 REPEATABLE-READ 下，行锁默认使用的是 Next-Key Lock。但是，如果操作的索引是唯一索引或主键，InnoDB 会对 Next-Key Lock 进行优化，将其降级为 Record Lock，即仅锁住索引本身，而不是范围。
共享锁和排他锁呢？ 不论是表级锁还是行级锁，都存在共享锁（Share Lock，S 锁）和排他锁（Exclusive Lock，X 锁）这两类：
（1)共享锁（S 锁） ：又称读锁，事务在读取记录的时候获取共享锁，允许多个事务同时获取（锁兼容）。
（2）排他锁（X 锁）：又称写锁/独占锁，事务在修改记录的时候获取排他锁，不允许多个事务同时获取。
如果一个记录已经被加了排他锁，那其他事务不能再对这条事务加任何类型的锁（锁不兼容）。 排他锁与任何的锁都不兼容，共享锁仅和共享锁兼容。
在索引失效的情况下，MySQL会把所有聚集索引记录和间隙都锁上，我们称之为锁表，或叫行锁升表锁.
那么对于 行锁升表锁，有的同学误以为行锁 升级变成了 表锁，但实际上锁的类型并没有发生变化，还是行锁! 只是表的所有聚集索引记录都被加上了行锁, 看起来像表锁
15、当前读和快照读有什么区别？
(1)快照读（一致性非锁定读）就是单纯的 SELECT 语句，但不包括下面这两类 SELECT 语句：
SELECT ... FOR UPDATE
SELECT ... LOCK IN SHARE MODE
快照即记录的历史版本，每行记录可能存在多个历史版本（多版本技术）。 快照读的情况下，如果读取的记录正在执行 UPDATE/DELETE 操作，读取操作不会因此去等待记录上 X 锁的释放，而是会去读取行的一个快照。
只有在事务隔离级别 RC(读取已提交) 和 RR（可重读）下，InnoDB 才会使用一致性非锁定读：
在 RC 级别下，对于快照数据，一致性非锁定读总是读取被锁定行的最新一份快照数据。
在 RR 级别下，对于快照数据，一致性非锁定读总是读取本事务开始时的行数据版本。
快照读比较适合对于数据一致性要求不是特别高且追求极致性能的业务场景。
(2)当前读 （一致性锁定读）就是给行记录加 X 锁或 S 锁。当前读的一些常见 SQL 语句类型如下：
-- 对读的记录加一个X锁
SELECT...FOR UPDATE
-- 对读的记录加一个S锁
SELECT...LOCK IN SHARE MODE
-- 对修改的记录加一个X锁
INSERT...
UPDATE...
DELETE...
15.1、能用 MySQL 直接存储文件（比如图片）吗？
可以是可以，直接存储文件对应的二进制数据即可。不过，还是建议不要在数据库中存储文件，会严重影响数据库性能，消耗过多存储空间。
15.2、 MySQL 如何存储 IP 地址？
可以将 IP 地址转换成整形数据存储，性能更好，占用空间也更小。MySQL 提供了两个方法来处理 ip 地址
INET_ATON() ：把 ip 转为无符号整型 (4-8 位)
INET_NTOA() ：把整型的 ip 转为地址插入数据前，先用 INET_ATON() 把 ip 地址转为整型，显示数据时，使用 INET_NTOA() 把整型的 ip 地址转为地址显示即可。
15.3、谨慎使用 MySQL 分区表
分区表在物理上表现为多个文件，在逻辑上表现为一个表； 谨慎选择分区键，跨分区查询效率可能更低； 建议采用物理分表的方式管理大数据。
15.4、 TIMESTAMP(4 个字节) 或 DATETIME (8 个字节) 存储时间
TIMESTAMP 存储的时间范围 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07TIMESTAMP 占用 4 字节和 INT 相同，但比 INT 可读性高 超出 TIMESTAMP 取值范围的使用 DATETIME 类型存储 经常会有人用字符串存储日期型的数据（不正确的做法） 缺点 1：无法用日期函数进行计算和比较 缺点 2：用字符串存储日期要占用更多的空间
