数据库面试题(开发者必看)

最新推荐文章于 2025-06-12 20:26:08 发布

Moonxiyue

最新推荐文章于 2025-06-12 20:26:08 发布

阅读量3.5k

点赞数 5

CC 4.0 BY-SA版权

分类专栏：数据库 sql 面试文章标签：数据库 sql

本文链接：https://blog.csdn.net/Moonxiyue/article/details/125416330

本文深入探讨了数据库的相关概念，包括存储过程的优缺点、数据库的范式理论、视图的使用场景、DML操作的差异、索引的作用与优缺点、事务的ACID特性、隔离级别，以及乐观锁与悲观锁。此外，还介绍了超键、候选键、主键、外键的概念，SQL约束类型，以及MySQL存储引擎如InnoDB和MyISAM的特性。文章强调了SQL优化策略，如使用索引、避免在索引列上使用NOT，并提供了数据库优化的思路，包括结构优化和服务器硬件优化。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

什么是存储过程？有哪些优缺点？

什么是存储过程？有哪些优缺点？

存储过程就像我们编程语言中的函数一样，封装了我们的代码(PLSQL、T-SQL)。

存储过程的优点：

能够将代码封装起来
保存在数据库之中
让编程语言进行调用
存储过程是一个预编译的代码块，执行效率比较高
一个存储过程替代大量T_SQL语句，可以降低网络通信量，提高通信速率

存储过程的缺点：

每个数据库的存储过程语法几乎都不一样，十分难以维护（不通用）
业务逻辑放在数据库上，难以迭代

三个范式是什么

三个范式是什么

第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：关键字段 → 非关键字段x → 非关键字段y

上面的文字我们肯定是看不懂的，也不愿意看下去的。接下来我就总结一下：

首先要明确的是：满足着第三范式，那么就一定满足第二范式、满足着第二范式就一定满足第一范式
第一范式：字段是最小的的单元不可再分 学生信息组成学生信息表，有年龄、性别、学号等信息组成。这些字段都不可再分，所以它是满足第一范式的
第二范式：满足第一范式,表中的字段必须完全依赖于全部主键而非部分主键。 其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的 学号为1024的同学，姓名为Java3y，年龄是22岁。姓名和年龄字段都依赖着学号主键。
第三范式：满足第二范式，非主键外的所有字段必须互不依赖 就是数据只在一个地方存储，不重复出现在多张表中，可以认为就是消除传递依赖 比如，我们大学分了很多系（中文系、英语系、计算机系……），这个系别管理表信息有以下字段组成：系编号，系主任，系简介，系架构。那我们能不能在学生信息表添加系编号，系主任，系简介，系架构字段呢？不行的，因为这样就冗余了，非主键外的字段形成了依赖关系(依赖到学生信息表了)！正确的做法是：学生表就只能增加一个系编号字段。