文章目录
范式
“优化数据数据存储方式”
-
建立科学的，规范的的数据库是需要满足一些规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。
-
范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。 目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。
-
满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。
-
一般说来，数据库只需满足第三范式（3NF）就行了。 通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。
范式间的差别是什么
第一范式——属性不可再分
1NF的定义为：符合1NF的关系中的每个属性都不可再分
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
如：姓名——地址——电话（电话包括手机和座机，要拆分开）
“第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。”
第二范式——属性完全依赖于主键。
2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。
接下来对这句话中涉及到的四个概念——“函数依赖”、“码”、“非主属性”、与“部分函数依赖”进行一下解释。
- 函数依赖： 我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。
- 部分函数依赖： 设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
- 完全函数依赖： 设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
- 传递函数依赖： 在关系模式R(U)中，设X，Y，Z是U的不同的属性子集，如果X确定Y、Y确定Z，且有X不包含Y，Y不确定X，（X∪Y）∩Z=空集合，则称Z传递函数依赖(transitive functional dependency) 于X。
第三范式——属性不能传递依赖于主属性
第三范式(3NF) 就是指表中的所有数据元素不但要能惟一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。也就是说，对于一个满足2nd NF 的数据结构来说，表中有可能存在某些数据元素依赖于其他非关键字数据元素的现象,必须消除。
通俗的说，第三范式（3NF）3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于：2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；
3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。
PS： BC范式（BCNF） 在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。
操作语句
数据库语句
嵌套查询in
【例】查询曾与刘晨一同上课的学生学号和姓名。（假设：一个课程只有一个上课班）
select distinct student.Sno as 学号, Sname as 姓名
from student,SC
where student.Sno=SC.Sno and Cno in (
select Cno
from SC,student
where SC.Sno=student.Sno and student.Sno in (
select Sno
from student
where student.Sname='刘晨'
)
)
-
上课类似的格式（附查询结果图）：https://blog.csdn.net/codema/article/details/80915311
-
超级全数据库查询语句：https://blog.csdn.net/hundan_520520/article/details/54881208
-
程序代码版：
https://blog.csdn.net/qq_41936662/article/details/80393172 -
mySQL常用复杂语句（练习完毕逻辑有一点点差）：
https://blog.csdn.net/fly910905/article/details/79846949 -
4的升级版——oracle中复杂SQL语句：
https://blog.csdn.net/bibibrave/article/details/80803717
要经常回顾复习。
Java连接MySQL语句
概念
- 事物四大特性：
【1】原子性：要么执行，要么不执行
【2】隔离性：所有操作全部执行完以前其它会话不能看到过程
【3】一致性：事务前后，数据总额一致
【4】持久性：一旦事务提交，对数据的改变就是永久的 - 索引的优缺点，什么时候使用索引，什么时候不能使用索引？
【1】索引最大的好处是提高查询速度，
【2】缺点是更新数据时效率低，因为要同时更新索引
【3】对数据进行频繁查询进建立索引，如果要频繁更改数据不建议使用索引。 - Sql的优化
【1】sql尽量使用索引,而且查询要走索引
【2】对sql语句优化
【3】子查询变成left join
【4】limit 分布优化，先利用ID定位，再分页
【5】or条件优化，多个or条件可以用union all对结果进行合并（union all结果可能重复）
【6】不必要的排序
【7】where代替having,having 检索完所有记录，才进行过滤
【8】避免嵌套查询 - varchar和char的使用场景
varchar： 字符长度经常变的
char： 用字符长度固定的 - 数据库连接池的作用
【1】维护一定数量的连接，减少创建连接的时间
【2】更快的响应时间
【3】统一的管理 - 关系型数据库和非关系型数据库区别
【1】关系型数据库：
优点：
1、容易理解：二维表结构是非常贴近逻辑世界一个概念，关系模型相对网状、层次等其他模型来说更容易理解；
2、使用方便：通用的SQL语言使得操作关系型数据库非常方便；
3、易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率；
4、支持SQL，可用于复杂的查询。
5.支持事务
缺点：
1、为了维护一致性所付出的巨大代价就是其读写性能比较差；
2、固定的表结构；
3、不支持高并发读写需求；
4、不支持海量数据的高效率读写
【2】非关系型数据库
1、使用键值对存储数据；
2、分布式；
优点：
无需经过sql层的解析，读写性能很高
基于键值对，数据没有耦合性，容易扩展
存储数据的格式：nosql的存储格式是key,value形式
缺点：
不支持事务 - 数据库中join的inner join, outer join, cross join
【1】left join
以A，B两张表为例
A left join B
选出A的所有记录，B表中没有的以null 代替
right join 同理
【2】inner join
A,B的所有记录都选出，没有的记录以null代替
【3】cross join (笛卡尔积)
A中的每一条记录和B中的每一条记录生成一条记录
例如A中有4条，B中有4条，cross join 就有16条记录 - 常见的数据库优化手段
答：库表优化，表设计合理化，符合三大范式；添加适当的索引（普通索引、主键索引、唯一索引、全文索引）；分库分表；读写分离等；sql语句优化，定位执行效率低，慢sql的语句，通过explain分析低效率的原因； - 数据库连接池
答：数据库连接池（Connection pooling）是程序启动时建立足够的数据库连接，并将这些连接组成一个连接池，由程序动态的对池中的连接进行申请、使用、释放；
（1）程序初始化时创建连接池
（2）使用时向连接池申请可用连接
（3）使用完毕，将连接返还给连接池
（4）程序退出时，断开所有的连接，并释放资源
回顾参考
比较简单：https://blog.csdn.net/zhan_zehong/article/details/21411883
短小精悍：https://www.cnblogs.com/ktao/p/7775100.html
概念1-7：https://blog.csdn.net/qq_22222499/article/details/79060495#1_4
写在最后
不会很正常，但既然知道面试的考察的知识点，罗列出来，仔细分析，认真思考，形成自己的见解，不断加入理解和更新，所谓终身学习，也是对自己的精进。
“早学可能会忘，但晚学或者不学你永远都不会学会好知识。”