1.非关系型数据库和关系型数据库区别,优势比较?
非关系型数据库的优势:
性能:NOSQL是基于键值对的,可以想象成表中的主键和值的对应关系,而且不需要经过SQL层的解析,所以性能非常高。
可扩展性:同样也是因为基于键值对,数据之间没有耦合性,所以非常容易水平扩展。
MongoDB:是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库中功能最丰富,最像关系数据库的。
MongoDB最大的特点是它支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,还支持为数据建立索引。它的特点是高性能、易部署、易使用、存储数据非常方便。
主要功能特性:
1)面向集合存储,易存储对象类型的数据。
2)模式自由。
关系型数据库的优势:
复杂查询:可以用SQL语句方便的在一个表以及多个表之间做非常复杂的数据查询。
事务支持:使得对于安全性能很高的数据访问要求得以实现。
其他:
(1.)对于这两类数据库,对方的优势就是自己的弱势,反之亦然。
(2.)NOSQL数据库慢慢开始具备SQL数据库的一些复杂查询功能,比如MongoDB。
(3.)对于事务的支持也可以用一些系统级的原子操作来实现例如乐观锁之类的方法来曲线救国,比如Redis set nx。
2.数据库范式:
第一范式:(确保每列保持原子性)所有字段值都是不可分解的原子值。第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。
第二范式:(确保表中的每列都和主键相关)在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。
第三范式:(确保每列都和主键列直接相关,而不是间接相关) 数据表中的每一列数据都和主键直接相关,而不能间接相关。
BCNF:符合3NF,并且,主属性不依赖于主属性。通常BC范式的条件有多种等价的表述:每个非平凡依赖的左边必须包含键码;每个决定因素必须包含键码。满足BC范式的关系都必然满足第三范式。
第四范式:要求把同一表内的多对多关系删除。
第五范式:从最终结构重新建立原始结构。
3.索引:数据库索引,是数据库管理系统中一个排序的数据结构,索引的实现通常使用B树及其变种B+树。
索引作用:
协助快速查询、更新数据库表中数据。
为表设置索引要付出代价的:
一、是增加了数据库的存储空间
二、是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。
4.事务:事务是对数据库中一系列操作进行统一的回滚或者提交的操作,主要用来保证数据的完整性和一致性。
事务四大特性(ACID)原子性、一致性、隔离性、持久性
事务的并发问题:
1、脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据
2、不可重复读:事务 A 多次读取同一数据,事务 B 在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果因此本事务先后两次读到的数据结果会不一致。
3、幻读:幻读解决了不重复读,保证了同一个事务里,查询的结果都是事务开始时的状态(一致性)。
事务隔离级别:
读未提交:另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据脏读
读已提交:事务 A 多次读取同一数据,事务 B 在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果因此本事务先后两次读到的数据结果会不一致。
可重复读:在同一个事务里,SELECT的结果是事务开始时时间点的状态,因此,同样的SELECT操作读到的结果会是一致的。但是,会有幻读现象
串行化:最高的隔离级别,在这个隔离级别下,不会产生任何异常。并发的事务,就像事务是在一个个按照顺序执行一样。
MySQL中默认事务隔离级别是“可重复读”时并不会锁住读取到的行
事务隔离级别:未提交读时,写数据只会锁住相应的行。
事务隔离级别为:可重复读时,写数据会锁住整张表。
事务隔离级别为:串行化时,读写数据都会锁住整张表。
查询中用到的关键词主要包含六个,并且他们的顺序依次为 select--from--where--group by--having--order by
数据库锁
MySQL有三种锁的级别:页级、表级、行级。
表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。
行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。
页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般
1.死锁:是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。
死锁产生原因:
(1) 因为系统资源不足。
(2) 进程运行推进的顺序不合适。
(3) 资源分配不当等。
死锁产生的四个必要条件:
(1) 互斥条件:一个资源每次只能被一个进程使用。
(2) 请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放。
(3) 不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺。
(4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
死锁预防
我们可以通过破坏死锁产生的4个必要条件来 预防死锁,由于资源互斥是资源使用的固有特性是无法改变的。
破坏“不可剥夺”条件:一个进程不能获得所需要的全部资源时便处于等待状态,等待期间他占有的资源将被隐式的释放重新加入到 系统的资源列表中,可以被其他的进程使用,而等待的进程只有重新获得自己原有的资源以及新申请的资源才可以重新启动,执行。
破坏”请求与保持条件“:第一种方法静态分配即每个进程在开始执行时就申请他所需要的全部资源。第二种是动态分配即每个进程在申请所需要的资源时他本身不占用系统资源。
破坏“循环等待”条件:采用资源有序分配其基本思想是将系统中的所有资源顺序编号,将紧缺的,稀少的采用较大的编号,在申请资源时必须按照编号的顺序进行,一个进程只有获得较小编号的进程才能申请较大编号的进程。
死锁避免
死锁避免的基本思想:系统对进程发出的每一个系统能够满足的资源申请进行动态检查,并根据检查结果决定是否分配资源,如果分配后系统可能发生死锁,则不予分配,否则予以分配,这是一种保证系统不进入死锁状态的动态策略。如果操作系统能保证所有进程在有限时间内得到需要的全部资源,则系统处于安全状态否则系统是不安全的。
悲观锁特点:先获取锁,再进行业务操作。
乐观锁的特点:先进行业务操作,不到万不得已不去拿锁。
mysql 高并发环境解决方案?
MySQL 高并发环境解决方案: 分库 分表 分布式 增加二级缓存。
需求分析:互联网单位 每天大量数据读取,写入,并发性高。
现有解决方式:水平分库分表,由单点分布到多点数据库中,从而降低单点数据库压力。
集群方案:解决DB宕机带来的单点DB不能访问问题。
读写分离策略:极大限度提高了应用中Read数据的速度和并发量。无法解决高写入压力。
mysql:数据库保存时间的类型——int和datetime的区别
我们都知道,时间保存在数据库中,可以选择使用两种类型,一种是int,一种是datetime
那么,它们两个有什么区别呢?要怎么用呢?
现在和小仓鼠一起来探讨一下
1、int和datetime的使用区别
(1)在数据库中显示方面:
int:int表示整数类型,那么它在数据库中显示的就是一连串的时间戳
datetime: datetime表示时间类型,那么它在数据库中显示的就是我们可视化的具体时间
(2) 各个优点和缺点
int:
优点:比较操作是直接的,例如一个access token在 7200秒後到期,用时间戳 就很简单地 +上7200 做比较就可以了
缺点:在数据库中,我们没办法直观的查看保存的日期
datetime:
优点: 可以直观的查看保存的日期
缺点:比较操作不够方便;储存日期到数据库之前要确定时区是正确的
Date:
只有日期,没具体的时分秒
1.五种类型所表示的日期格式(为了显而易见,字段名即类型名)
year 年
date 年-月-日
time 时:分:秒
datetime 年-月-日 时:分:秒
timestamp 年-月-日 时:分:秒
2. datetime 与timestamp 的区别
timestamp需要 4 字节的存储空间,而 datetime 则需要 8 字节
1.存储时间的方式不同
datatime设置的是什么时间就是什么时间;
timestamp则是把客户端插入的时间从当前时区转化为UTC(世界标准时间)进行存储。查询时,将其又转化为客户端当前时区进行返回。
2.存储的范围不同
timestamp存储的范围为:’1970-01-01 00:00:01.000000’ 到 ‘2038-01-19 03:14:07.999999’;
datetime 存储的范围为:’1000-01-01 00:00:00.000000’ 到 ‘9999-12-31 23:59:59.999999’。
3.timestamp不能为null,且timestrap增改会跟操作时间保持一致(客户端经处理的当前时间)
由于原因1存储方式不同,timestamp无论增改都是根据将客户端的当前时间转为UTC(世界标准时间)来存储,所以timestamp不为空,单条记录的数据行字段类型为timestamp的列值为最后一次操作的时间(修改其他列的数据,同行数据类型为timestrap的列值会变为客户端经处理的当前时间)。
————————————————
版权声明:本文为CSDN博主「不积小流无以成江海-IT」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_29039853/article/details/82468847