Serializable带来了别的什么问题
该隔离级别需要加锁实现,因为要使用加锁机制保证同一时间只有一个事务执行,也就是保证事务串行执行。这种事务隔离级别效率低下,比较耗数据库性能,一般不使用
delete,drop,truncate 的区别
delete,drop,truncate
drop > truncate > delete
- DELETE语句执行删除的过程是每次从表中删除一行,并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作,TRUNCATETABLE则一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存,删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。
- 当表被TRUNCATE 后,这个表和索引所占用的空间会恢复到初始大小,DELETE操作不会减少表或索引所占用的空间。drop语句将表所占用的空间全释放掉。
- TRUNCATE 只能对TABLE; DELETE可以是table和view
- truncate、drop是DLL(data define language),操作立即生效,原数据不放到 rollback segment中,不能回滚
- TRUNCATE TABLE 删除表中的所有行,但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值,请改用 DELETE。如果要删除表定义及其数据,请使用 DROP TABLE 语句。
MVCC详解
什么是MVCC
MVCC(multiple-version-concurrent-control)是
一种控制并发的方法,主要用来提高数据库的并发
性能。MVCC的作用就是在不加锁的情况下,解决数
据库读写冲突问题,并且解决脏读、幻读、不可重
复读等问题,但是不能解决丢失修改问题。
数据丢失修改问题:事务A和事务B都对同一个数据
进行修改,事务A先修改,事务B随后修改,事务B
的修改覆盖了事务A的修改。
在了解MVCC时应该先了解当前读和快照读。
1.当前读:读取的是数据库的最新版本,并且在读
取时要保证其他事务不会修该当前记录,所以会对
读取的记录加锁。
2.快照读:不加锁读取操作即为快照读,使用MVCC
来读取快照中的数据,避免加锁带来的性能损耗。
读已提交:每条sql语句前建立一个视图
可重复读:事务开始之前建立一个视图
MVCC的实现原理:
1.版本号
系统版本号:是一个自增的ID,每开启一个事
务,系统版本号都会递增。
事务版本号:事务版本号就是事务开始时的系
统版本号,可以通过事务版本号的大小判断事
务的时间顺序。
2.行记录隐藏的列
DB_ROW_ID:所需空间6byte,隐含的自增ID,用来生成聚簇索引,如果数据表没有指定聚簇索引,InnoDB会利用这个隐藏ID创建聚簇索引
DB_TRX_ID:所需空间6byte,最近修改的事务ID,记录创建这条记录或最后一次修改这条记录的事务ID。
DB_ROLL_PTR:所需空间7byte,回滚指针,指向这条记录的上一个版本。
3.undo日志
MVCC使用到的快照会存储在Undo日志中,该
日志通过回滚指针将一个一个数据行的所有快
照连接起来
数据库锁的类型有哪些?
锁粒度分为:行级锁,表级锁,页面锁
MyISAM默认采用表级锁,InnoDB默认采用行级锁。
从锁的类别上区别可以分为共享锁和排他锁
共享锁:
共享锁又称读锁,简写为S锁,一个事务对一个数
据对象加了S锁,可以对这个数据对象进行读取操
作,但不能进行更新操作。并且在加锁期间其他事
务只能对这个数据对象加S锁,不能加X锁。
排他锁:
排他锁又称为写锁,简写为X锁,一个事务对一个
数据对象加了X锁,可以对这个对象进行读取和更
新操作,加锁期间,其他事务不能对该数据对象进
行加X锁或S锁
MySQL中InnoDB引擎的行锁模式及其是如何实现的
行锁实现方式:
INnoDB的行锁是通过给索引上的索引项加锁实现的
,如果没有索引,InnoDB将通过隐藏的聚簇索引来
对记录进行加锁。
InnoDB行锁主要分三种情况:
1.Record lock:对索引项加锁
2.Grap lock:对索引之间的“间隙”、第一条记录
前的“间隙”或最后一条后的间隙加锁。
3.Next-key-lock:前两种放入组合,对记录及前面的间隙加锁
InnoDB行锁的特性:如果不通过索引条件检索数据
,那么InnoDB将对表中所有记录加锁,实际产生的
效果和表锁是一样的。
MVCC不能解决幻读问题,在可重复读隔离级别下,使用MVCC+Next-Key Locks可以解决幻读问题。
一致性锁定读
select…for update:对读取的行加X锁
select…lock in share mode:加一个S锁
什么是数据库的乐观锁和悲观锁,如何实现?
乐观锁:系统假设数据的更新在大多数时候是不会
产生冲突的,所以数据库只在更新操作提交的时候
对数据检测冲突,如果存在冲突,则数据更新失
乐观锁实现方式:一般通过版本号和CAS算法实现
悲观锁:假定会发生并发冲突,屏蔽一切可能违反
数据完整性的操作。通俗讲就是每次去拿数据的时
候都认为别人会修改,所以每次在拿数据的时候都
会上锁。
悲观锁的实现方式:通过数据库的锁机制实现,对
查询语句添加for updata。
什么是死锁?如何避免?
什么是死锁:
死锁是指两个或者两个以上进程在执行过程中,由
于竞争资源或者由于彼此通信而造成的一种阻塞的
现象。在MySQL中,MyISAM是一次获得所需的全部
锁,要么全部满足,要么等待,所以不会出现死锁
。在InnoDB存储引擎中,除了单个SQL组成的事务
外,锁都是逐步获得的,所以存在死锁问题。
如何避免
1.在事务中,如果需要更新记录,应直接申请足够
级别的排他锁,而不应该先申请共享锁,更新时在
申请排他锁,因为在当前用户申请排他锁时,其他
事务可能已经获得了相同记录的共享锁,从而造成
锁冲突或者死锁。
2.尽量使用较低的隔离级别
3.合理选择事务的大小,小事务发生锁冲突的概率更低
4.如果不同的程序并发存取多个表,尽量以相同的
顺序访问表。
mongodb 与 mysql的差别
1.mysql是关系型数据库,mysql采用table和结构化的sql语句来处理数据,在mysql中需要
预先定义数据结构schema,并定义table中数据字段的关系。
在mysql中,相关信息可以保存在不同的表中,通过join的形式来保持彼此关联
2.mongoDB是菲关系数据库,采用类JSON的documents来存储数据,一般会将热点数据存储到
内存中,读取效率高
3.mongoDB具备高扩展性和延展性和自动分片机制(auto-sharding)
1、mysql是RDBMS关系型数据库、redis和mongodb是Nosql非关系型数据库;
2、关系型数据库因为注重事务,所以就要符合ACID特性,所谓的原子性、一致性、持久性
、隔离型;
3、Nosql非关系型数据库相对于CAP理论来讲,最多只能满足两个,其中mongodb和redis均是满足CP;
4、当你的数据为结构化数据,符合关系型数据库的标准时,优先考虑使用mysql等关系型数
据库,因为发展悠久,社区强大,数据量太大考虑优化、分库分表等策略;
5、当你的数据不符合关系型数据库的标准,考虑使用mongodb等非关系型数据库,数据量大时考虑分布式集群;
6、redis是完全基于内存的,存储数据量较mongodb少,所以不单独用来作为业务数据库存
储,可以配合mysql、mongodb等解决有实时数据获取需求的快速处理;
CAP;一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)
对事务的详解
https://www.cnblogs.com/xuehao/p/14355554.html
数据库三范式 冗余
http://www.blogjava.net/xzclog/archive/2009/01/04/249711.html
第一范式:无重复的列
指数据库表的每一列都是不可分割的基本数据项,表中的列的具有原子性,不可再分解,即列的信息,不能分解,同一列中不能有多个值,比如说有属性为性格,你后面跟的列就只能是男或者女,而不是男 女一起。第一范式(1NF
)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库
第二范式:属性完全依赖与主键
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须
先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一
地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。例如员工信息
表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以
被惟一区分。这个惟一属性列被称为主关键字或主键、主码。