MySQL

数据库三范式：

• 第一范式：列不可再分；
• 第二范式：行可以唯一区分，主键约束；
• 第三范式：表的非主属性不能依赖与其他表的非主属性外键约束；
• 三大范式是一级一级依赖的，第二范式建立在第一范式上，第三范式建立在第一第二范式上；

数据库引擎：

• MYISAM：全表锁，拥有较高的执行速度，不支持事务，不支持外键，并发性能差，占用空间较小，对事务完整性没有要求，以select、insert为主的应用基本上可以使用该引擎
• Innodb：行级锁，提供了具有提交、回滚和崩溃恢复能力的事务安全，支持自动增长列，支持外键约束，并发能力强，占用空间是MYISAM的2.5倍，处理效率相对会差一些
• Memory：全表锁，存储在内容中，速度快，但会占用和数据量成正比的内存空间且数据在mysql重启时会丢失，默认使用HASH索引，检索效率非常高，但不适用于精确查找，主要员工与哪些内容变化不频繁的代码表
• MERGE：是一组MYISAM表的组合

InnoDB	MyISAM
支持事务，默认每一条SQL都封装成事务，自动提交，会影响速度，把多条SQL放在begin和commit之间，组成一个事务	不支持事务
支持外键，包含外键的InnoDB转为MYISAM会失败	不支持外键
聚集索引，数据文件和索引在一起的，必须要有主键，通过主键索引效率很高。主键不应过大	非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。逐渐索引和辅助索引是独立的
不保存表的具体行数	用一个变量保存了整个表的行数
不支持全文索引	支持全文索引

索引：加快数据库的检索速度；降低了插入、删除、修改等维护任务的速度；唯一索引可以确保每一行数据的唯一性；通过使用索引，可以在查询的过程中使用优化隐藏器，提高系统的性能；需要占物理和数据空间。

1. 主键索引（PRIMARY）
2. 唯一索引（UNIQUE）
3. 普通索引（INDEX）
4. 全文索引（FULLTEXT）

视图：是一种虚拟的表，具有和物理表相同的功能。可以对视图进行增，改，查，操作，视图通常是有一个表或者多个表的行或列的子集。对视图的修改不影响基本表。比起多表查询可以跟容易获取数据。

数据库的事务：多条sql语句，要么全部成功，要么全部失败；

事务的特性：

1. 原子性：组成一个事务的多个数据库操作是一个不可分割的原子单位，只有所有操作都成功，整个事务才会提交，任何一个操作失败，已经执行的任何操作都必须撤销，让数据库返回初始状态。
2. 一致性：事务操作成功后，数据库所处的状态和业务规则是一致的。数据不会被破坏。
3. 隔离性：在并发数据操作时，不同的事务拥有各自的数据空间，各自操作不会对彼此产生干扰。
4. 持久性：一旦事务提交成功，事务中的所有操作都必须持久化到数据库中。

并发事务引起的问题：多个事务并发运行，会操作相同的数据来完成各自的任务。

1. 脏读：一个事务正在访问数据并对数据进行修改，还未提交到数据库时另一个事务也访问到了这个数据，然后使用这个事务。产生了脏数据。
2. 丢失修改：一个事务读取一个数据时，另一个事务也读取到该数据，第一个事务修改了该数据时第二个事务也修改了该数据，第一个事务的修改结果就会丢失。
3. 不可重复读：一个事务内多次读取同一数据，该事务未结束时，另一个事务也访问该数据并对该数据进行修改，就导致第一个事务前后读取到的数据不同。
4. 幻读：一个事务读取数据时另一个并发事务插入了一些数据，第一个事务前后读取数据不一致。

事务隔离级别：

• READ-UNCOMMITTED（读取未提交）：最低隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读；
• READ-COMMITTED（读取已提交）：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生；
• （默认隔离界别）REPEATABLE-READ（可重复读）：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读还有可能发生；
• SERIALIZABLE（可串行化）：最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，该级别可以防止脏读、不可重复读以及幻读。

drop	删除数据和表数据	速度最快	ddl，操作立即生效，原数据不放到rollback segment中，不能回滚，操作不触发trigger
truncate	只删除数据，不删除表结构	速度适中	ddl，操作立即生效，原数据不放到rollback segment中，不能回滚，操作不触发trigger
delete	只删除数据，不删除表结构	速度最慢	dml，操作会放到rollback segement中，事务提交之后才生效，执行时会触发trigger

内联接、左外联接、右外联接：

• 内联接（Inner Join）：匹配两张表中相关联的记录；
• 左外联接（Left Outer Join）：除了匹配两张表中相关联的记录外，还会匹配左表中剩余的记录，右表中未匹配到的字段用NULL表示；
• 右外联接（Right Outer Join）：除了匹配两张表中相关联的记录外，还会匹配右表中剩余的记录，左表中未匹配到的字段用NULL表示。

SQL优化：

1. 尽量不要使用select *;
2. 尽量减少子查询，使用关联查询（left join,right join,inner join）替代；
3. 减少使用IN或者NOT IN ，使用exists,not exists或者关联查询语句替代；
4. or的查询尽量用union或者union all代替（确认没有重复数据或不用剔除重复数据时，union all会更好）；
5. 尽量避免在where子句中使用!=或者<>操作符，否则将导致引擎直接放弃使用索引而进行全表扫描；
6. 应避免在where子句中对字段进行null值判断，否则将导致引擎放弃使用索引而进行全表扫描。

大表优化：单表记录数过大时，数据库的CRUD性能会下降。

1. 限定数据的范围：尽量使用带限制数据范围条件的查询语句；
2. 读/写分离：主库写，从库读；
3. 水平分区：保持数据结构不变，通过某种策略存储数据分片；可以支撑非常大的数据量；最好分库。
4. 垂直分区：根据数据库里面的数据表的相关性进行拆分；把一张列比较多的表拆分为多张表 

优点	使列数据变小，在查询时减少读取的Block数，减少I/O次数；简化表结构，易于维护；
缺点	主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决；会让事务变的更加复杂；

分库分表后id主键的处理：

• UUID：不适合做主键，太长，无序不可读，查询效率低；适合用于生成唯一的名字表示；
• 数据库自增id：有序，需要独立部署数据库实例，成本高，有性能瓶颈；
• 利用redis生成id：性能好，灵活方便，不依赖数据库；引入新组建造成系统更复杂，可用性降低，编码更复杂，增加了系统成本；
• 美团的Leaf分布式ID生成系统：Leaf是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，需要依赖关系数据库、Zookeeper等中间件。