原文出处：https://juejin.im/post/5a9ca0d6518825555c1d1acd
作者：Java3y
本文在原文基础上进行修改，而且没有特定针对MySQL.
一、存储过程（以及函数）
定义理解：
存储过程和函数是事先经过编译并存储在数据库中的一段SQL语句的集合。
二者的区别：
- 函数必须有返回值，而存储过程没有；
- 函数的参数只能是IN类型，存储过程的参数可以使用IN、OUT、INOUT类型。
优点：
对代码进行封装，功能强大，调用方便；
将数据处理放在数据库服务器上，减少业务系统与数据库的交互；
存储过程是一个预编译的代码块，执行效率高；
缺点：
如果存储过程中有大量的复杂运算，会占用数据库服务器的CPU，造成数据库服务器的压力；
不同数据库的存储过程语法不一致，难以通用和维护；
业务逻辑放在数据库中，难以迭代；
过多地使用存储过程会降低系统的可移植性。
哪些应用场景适合使用存储过程？
在商业数据库的应用领域，例如金融、企业、政府等，存储过程使用广泛，因为其业务相对稳定，而且要求数据非常准确不出错。这样的逻辑一旦调试通过，将会很长时间不需要改动。甚至一些政务项目的核心逻辑都会用存储过程编写。
但是，也有码农反应，十年前使用DB2时，存储过程被大量使用，基于Oracle的应用，存储过程已经不被推荐使用，一是因为逻辑不方便移植，二是消耗数据库资源。
不适合大规模应用存储过程的场景：
- 需求经常改变，导致数据库结构经常需要调整。若修改一个表，就需要N个相关的存储过程，这是噩梦。例如互联网行业，需求变更频繁。（一个原因是MySQL的广泛使用，而它的存储过程功能较弱。）（有很多人反对这点，因为觉得改存储过程比其改应用代码来说，要少很多痛苦。）
- 数据需要迁移，例如原来使用SQL Server，现在想用Oracle，也是噩梦，因为不同数据库的厂商提供的SQL函数不一样。
- 商业逻辑要求聚合多种格式、多个来源的数据，并且要进行数据适配，这种工作放在中间层而不是数据库里实现。
- 数据库集群，需要实现数据库Server端存储过程代码变更同步，十分麻烦；
- 很多NoSQL数据库，比如MongoDB，本身没有存储过程的概念。
二、关于数据库设计的三个范式
首先要明确，满足第三范式，就必定满足第二范式；满足第二范式，就必定已经满足第一范式。
我之前的文章：数据库设计与三大范式
三、视图
为什么需要视图？
对于同一张表，A用户只关新部分字段，B用户只关心另一些字段，那么此时把全部的字段都显示给他们看，是不合理的。
所以我们需要提供了一个表的“视图”，给到他们想看的数据的同时，屏蔽掉其它字段的数据。
视图的是怎么实现的？
视图是保存在数据库中的select查询。
其它方面，我前面的文章有提到。
四、drop、delete、truncate分别在什么场景下使用
drop table:
- 1)属于DDL
- 2)不可回滚
- 3)不可带where
- 4)表内容和结构删除
- 5)删除速度快
truncate table
- 1)属于DDL
- 2)不可回滚
- 3)不可带where
- 4)表内容删除
- 5)删除速度快
delete from
-
1)属于DML
-
2)可回滚
-
3)可带where
-
4)表结构在，表内容要看where执行的情况
-
5)删除速度慢,需要逐行删除
总结：
- 不再需要一张表时，用drop；
- 想删除部分数据行时，用带where的delete；
- 保留表，清空表中数据时，用truncate；
五、索引
索引的知识点前面都提过，但是还没涉及到更深的它到底是 如何工作的，比如索引表是什么？它存储在哪？等问题
这里只列出最常见的两个问题。
什么样的表需要创建索引？什么样的字段适合创建索引？
什么样的表要避免使用索引？什么样的字段不适合创建索引？
六、事务
事务的ACID属性：
原子性（Atomicity）：事务中的所有元素必须作为一个整体提交或回滚。
一致性（Consistency）：事务完成时，数据必须处于一致状态。在事务进行中，可能会不一致。如转账操作中的金额总量。
隔离性（Isolation）：对数据进行修改的所有并发事务是彼此隔离的，即事务是独立的。
持久性（Durability）：指不管系统是否发生了故障，事务处理的结果都是永久的。就是说一旦事务被提交，事务的效果会被永久地保留在数据库中。
事务的隔离级别：
编写事务的原则：
- 事务尽可能简短，较大的事务占用的资源很多；
- 事务中访问的数据量尽量少，这样事务之间对资源的争夺就少；
- 查询数据不要使用事务；
- 事务处理的过程中尽量不要出现等待用户输入的操作。
七、数据库的乐观锁、悲观锁（即锁问题）