浅谈一下mysql数据库底层原理

1.数据库事务的基本特性。

原子性:

事务中的所有操作要么全部提交成功,要么全部失败回滚。

场景:UPDATE cs_user SET age = 18 , gender = '女' WHERE id = 4。要么全部更新要么更新失败,不会出现age更新成功,gender更新失败。

一致性

据库总是从给一个一致性的状态转换到另一个一致性的状态。

场景:比如规定某个表的字段age大于等于12小于18时,字段type为青少年,而数据库中存在age=16的时候,type='儿童'。

隔离性:

一个事务所做的修改在提交之前对其它事务是不可见的。两个以上的事务不会出现交错执行的状态.因为这样可能会导致数据不一致。

持久性:

一旦事务提交,其所做的修改便会永久保存在数据库中。

事务在并发环境下出现的问题。

脏读(Dirty Read):一个事务读取了另一个事务未提交的数据。如果另一个事务回滚,则读取的数据将是无效的。

不可重复读(Non-repeatable Read):同一事务内,两次读取同一数据得到的结果不同。这是因为在两次读取之间,另一个事务修改了该数据。

幻读(Phantom Read):同一事务内,两次查询得到的结果集不同。这是因为在两次查询之间,另一个事务插入或删除了一些数据。

丢失修改(Lost Update):两个或多个事务同时修改同一数据,其中一个事务的修改被另一个事务覆盖,导致修改丢失。

不可重复读的和幻读很容易混淆,不可重复读侧重于修改,幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行,解决幻读需要锁表。

对于这些问题的解决方法一般是有:事务隔离级别,乐观锁和悲观锁,MVCC(多版本并发控制)。

事务隔离级别

数据库提供了多种事务隔离级别,不同的隔离级别提供了不同的并发控制机制,以解决并发问题。

以下是数据库的每一个事务隔离级别的详细介绍:

READ UNCOMMITTED(读未提交):该隔离级别允许事务读取其他事务未提交的数据,可能会出现脏读、不可重复读和幻读的问题。

READ COMMITTED(读已提交):该隔离级别只允许事务读取其他事务已提交的数据,可以避免脏读问题,但不可避免不可重复读和幻读的问题。

REPEATABLE READ(可重复读):该隔离级别保证在同一事务中多次读取同一数据得到的结果是一致的,可以避免脏读和不可重复读的问题,但无法避免幻读。

SERIALIZABLE(串行化):该隔离级别保证事务串行执行,避免了以上所有并发问题,但会影响并发性能。

READ UNCOMMITTED(读未提交)

在READ UNCOMMITTED级别下,事务可以读取未提交的数据,没有对数据进行加锁或版本控制。当一个事务读取数据时,即使另一个事务正在修改该数据,也不会阻塞读取操作。这种实现方式可以提高读取性能,但会导致脏读的问题。

优点:

读取性能高:由于不需要加锁或版本控制,因此读取性能较高。

无锁操作:该隔离级别不需要对数据进行加锁操作,因此可以避免锁的竞争问题。

缺点:

脏读问题:在READ UNCOMMITTED级别下,事务可以读取其他事务未提交的数据,因此可能会读取到无效数据,导致脏读的问题。

不可重复读问题:由于其他事务可以修改数据,因此同一事务内两次读取同一数据得到的结果可能不同。

幻读问题:由于其他事务可以插入或删除数据,因此同一事务内两次查询得到的结果集可能不同。可能导致数据不一致:由于读取的数据可能是未提交的数据,因此可能会导致数据不一致的问题。

对于这个隔离级别,几乎无法解决任何对于数据库并发环境下数据不一致的错误,但在一些对数据一致性要求不高,但读取性能要求较高的系统中,可以考虑使用该隔离级别。

READ COMMITTED(读已提交)

在READ COMMITTED级别下,事务只能读取已提交的数据,需要对数据进行加锁或版本控制。当一个事务读取数据时,如果另一个事务正在修改该数据,则需要等待该事务提交后才能读取。这种实现方式可以避免脏读的问题,但可能会无法避免不可重复读和幻读的问题。

优点:

避免脏读问题:由于只允许读取已提交的数据,因此可以避免脏读的问题。

数据一致性较高:由于只读取已提交的数据,因此数据一致性较高。

缺点:

不可重复读问题:由于其他事务可以修改数据,因此同一事务内两次读取同一数据得到的结果可能不同。

幻读问题:由于其他事务可以插入或删除数据,因此同一事务内两次查询得到的结果集可能不同。

锁的竞争问题:由于需要对数据进行加锁,因此可能会导致锁的竞争问题。

这个隔离级别解决了一部分并发问题,但是还有一部分问题没有解决,适合应用于对数据一致性要求较高的系统。如果需要更高的隔离级别,可以考虑使用REPEATABLE READ或SERIALIZABLE级别。

REPEATABLE READ(可重复读)

在InnoDB中是这样的:RR隔离级别保证对读取到的记录加锁 (记录锁),同时保证对读取的范围加锁,新的满足查询条件的记录不能够插入 (间隙锁),因此不存在幻读现象。但是标准的RR只能保证在同一事务中多次读取同样记录的结果是一致的,而无法解决幻读问题。InnoDB的幻读解决是依靠MVCC的实现机制做到的。Mysql默认的隔离级别是RR。

优点:

避免脏读和不可重复读问题:由于需要对数据进行版本控制,因此可以避免脏读和不可重复读的问题。

数据一致性较高:由于保证了同一事务内多次读取同一数据得到的结果一致,因此数据一致性较高。

缺点:

锁的竞争问题:由于需要对数据进行版本控制,因此可能会导致锁的竞争问题。

版本控制开销:由于需要对数据进行版本控制,因此可能会增加数据库的存储和计算开销。

幻读解决

InnoDB的幻读解决是依靠MVCC的实现机制: (增加系统版本号,每次事务操作,会比较系统版本号) InnoDB为每行记录添加了一个版本号(系统版本号),每当修改数据时,版本号加一。在读取事务开始时,系统会给事务一个当前版本号,事务会读取版本号<=当前版本号的数据,这时就算另一个事务插入一个数据,并立马提交,新插入这条数据的版本号会比读取事务的版本号高,因此读取事务读的数据还是不会变。例如:此时books表中有5条数据,版本号为1 事务A,系统版本号2:select * from books;因为1<=2所以此时会读取5条数据。 事务B,系统版本号3:insert into books ...,插入一条数据,新插入的数据版本号为3,而其他的数据的版本号仍然是2,插入完成之后commit,事务结束。 事务A,系统版本号2:再次select * from books;只能读取<=2的数据,事务B新插入的那条数据版本号为3,因此读不出来,解决了幻读的问题,而且两个事务同时修改同一数据,则会生成两个不同的版本,从而避免数据丢失的问题,解决了丢失修改问题。

mysql锁

在mysql中使用的锁一般是两种类型,乐观锁和悲观锁。

乐观锁概念

是由我们自己实现的一个版本控制。在表中的数据进行操作时(更新),先给数据表加一个版本(version)字段,每操作一次,将那条记录的版本号加1。也就是先查询出那条记录,获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等,如果相等,则说明这段期间,没有其他程序对其进行操作,则可以执行更新,将version字段的值加1;如果更新时发现此刻的version值与刚刚获取出来的version的值不相等,则说明这段期间已经有其他程序对其进行操作了,则不进行更新操作

悲观锁概念

这个由数据库实现,对于悲观锁在操作数据时,认为此操作会出现数据冲突,所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作。在悲观锁中又有两种类型,分别是共享锁与排它锁。

共享锁(读锁)

对于共享锁来说,他的作用是在一个事务对数据A加上共享锁后,其他的事务只能在对数据A加共享锁,无法加其他锁,只有全部共享锁释放后才能加其他锁(基本上就是排它锁)。这句话的意思其实就是,有一个事务正在读数据A,那么其他事务也只能读数据A,而无法修改数据A,只有在所有事务对数据A的访问都完成后,才能进行修改。

排它锁(写锁)

对于排它锁来说,作用是在一个事务对数据A加上排它锁后,只有这个事务可以对数据进行读取和修改,其他的事务都无法对这个数据进行读取和修改,当然也无法对这个数据加锁。

使用方式:在需要执行的语句后面加上for update就可以了

行锁和表锁

对于悲观锁来说

有行锁和表锁两种区别,

行锁是给某一行加上锁,也就是一条记录加上锁。

行级锁都是基于索引的,如果一条SQL语句用不到索引是不会使用行级锁的,会使用表级锁(这也是为什么sql语句尽量保证走索引原因之一)

表锁:没有使用索引的情况是锁定全表的。

死锁

死锁(Deadlock) 所谓死锁:是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。由于资源占用是互斥的,当某个进程提出申请资源后,使得有关进程在无外力协助下,永远分配不到必需的资源而无法继续运行,这就产生了一种特殊现象死锁。

到此这篇关于浅谈一下mysql数据库底层原理的文章就介绍到这了,更多相关mysql数据库底层原理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 关于mysql数据库连接编码问题

    前几天使用springboot做一个数据库查询功能,发现使用中文就无法查到数据,经过测试SQL语句是没有问题的,但是就是查询不到数据,一直显示为null. 后来,我灵机一动尝试了一下查询参数改为英文,显示出查询结果是正常的.这就说明了是编码的问题. 起初我以为是springboot的编码问题,但是我尝试了之后发现是正常的,后来经过搜索查询发现是JDBC的url没有指定编码,所以mysql服务端使用了默认的编码来解码导致了错误. 查询数据经过网络传输,网络上的数据都是字节了,如果不指定编码的话,只

  • MySQL数据库的性能优化

    目录 一.MySQL数据库的优化目标.基本原则: 1.优化目标: 2.基本原则: 二.定位分析SQL语句的性能瓶颈: 1.通过show status 命令了解各种SQL的执行效率: 2.定位执行效率较低的SQL语句 3.通过explain分析慢SQL的执行计划 4.通过show profile 分析SQL的具体耗时瓶颈 三.数据库的优化方法: 一.MySQL数据库的优化目标.基本原则: 1.优化目标: MySQL数据库是常见的两个瓶颈是CPU和I/O的瓶颈,无论是索引优化.还是表结构优化,参数优

  • 查询数据库空间(mysql和oracle)

    目录 Mysql版 1.查看所有数据库容量大小 2.查看所有数据库各表容量大小 3.查看指定数据库容量大小 4.查看指定数据库各表容量大小 5.查看指定数据库各表信息 oracle版 1.查看表所占的空间大小 2.查看表空间的使用情况 3.查看回滚段名称及大小 5.查看日志文件 6.查看数据库对象 7.查看数据库版本 8.查看数据库的创建日期和归档方式 9.查看表空间是否具有自动扩展的能力 oracle加强版 一.查看表空间使用率 1.查看数据库表空间文件: 2.查看所有表空间的总容量: 3.查

  • 关于node+mysql数据库连接池连接

    mysql有两种连接方式:一种是直接连接 另一种是池化连接,我们这篇讲的是池化连接. 为了让解惑,我简答的写份直接连接的代码,如下: var mysql = require('mysql'); var connection = mysql.createConnection({ host : 'localhost', user : 'ac', password : '123456', database : 'textPro' }); connection.connect(); connection

  • 浅谈一下mysql数据库底层原理

    1.数据库事务的基本特性. 原子性: 事务中的所有操作要么全部提交成功,要么全部失败回滚. 场景:UPDATE cs_user SET age = 18 , gender = '女' WHERE id = 4.要么全部更新要么更新失败,不会出现age更新成功,gender更新失败. 一致性: 据库总是从给一个一致性的状态转换到另一个一致性的状态. 场景:比如规定某个表的字段age大于等于12小于18时,字段type为青少年,而数据库中存在age=16的时候,type='儿童'. 隔离性: 一个事

  • 浅谈为什么Mysql数据库尽量避免NULL

    在Mysql中很多表都包含可为NULL(空值)的列,即使应用程序并不需要保存NULL也是如此,这是因为可为NULL是列的默认属性.但我们常在一些Mysql性能优化的书或者一些博客中看到观点:在数据列中,尽量不要用NULL 值,使用0,-1或者其他特殊标识替换NULL值,除非真的需要存储NULL值,那到底是为什么?如果替换了会有什么好处?同时又有什么问题呢?那么就看下面: (1)如果查询中包含可为NULL的列,对Mysql来说更难优化,因为可为NULL的列使得索引,索引统计和值比较都更复杂. (2

  • 浅谈mysql join底层原理

    目录 join算法 驱动表和非驱动表的区别 1.Simple Nested-Loop Join,简单嵌套-无索引的情况 2.Index Nested-Loop Join-有索引的情况 3.Block Nested-Loop Join ,join buffer缓冲区 缓冲区大小 数据量大的表和数据量小的表如何选择连接顺序 细节 join算法 mysql只支持一种join算法:Nested-Loop Join(嵌套循环连接),但Nested-Loop Join有三种变种: Simple Nested

  • 浅谈三种数据库的 SQL 注入

    目录 SQL 注入原理 SQL 注入分类 1. 数字型注入 2. 字符型注入 3. 其他类型 常见数据库的注入 SQL Server MySQL Oracle SQL 注入原理 SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序,而这些输入大都是SQL语法里的一些组合,通过执行SQL语句进而执行攻击者所要的操作,其主要原因是程序没有细致地过滤用户输入的数据,致使非法数据侵入系统. SQL 注入分类 1. 数字型注入 当输入的参数为整型时,则有可能存在数字型注入漏洞. 假设存在一条

  • 深入理解 MySQL 索引底层原理

    目录 Mysql 索引底层数据结构选型 哈希表(Hash) 二叉查找树(BST) AVL 树和红黑树 B 树 5.B+树 Innodb 引擎和 Myisam 引擎的实现 MyISAM 引擎的底层实现(非聚集索引方式) Innodb 引擎的底层实现(聚集索引方式) 一步一步推导出 Mysql 索引的底层数据结构. Mysql 作为互联网中非常热门的数据库,其底层的存储引擎和数据检索引擎的设计非常重要,尤其是 Mysql 数据的存储形式以及索引的设计,决定了 Mysql 整体的数据检索性能. 我们知

  • 浅谈为什么MySQL不建议delete删除数据

    前言 我负责的有几个系统随着业务量的增长,存储在MySQL中的数据日益剧增,我当时就想现在的业务方不讲武德,搞偷袭,趁我没反应过来把很多表,很快,很快啊都打到了亿级别,我大意了,没有闪,这就导致跟其Join的表的SQL变得很慢,对的应用接口的response time也变长了,影响了用户体验. 事后我找到业务方,我批评了他们跟他们说要讲武德,连忙跟我道歉,这个事情才就此作罢,走的时候我对他们说下次不要这样了,耗子尾汁,好好反思. 骂归骂,事情还是得解决,时候我分析原因发现,发现有些表的数据量增长

  • 浅谈Mybatis+mysql 存储Date类型的坑

    场景: 把一个时间字符串转成Date,存进Mysql.时间天数会比实际时间少1天,也可能是小时少了13-14小时 Mysql的时区是CST(使用语句:show VARIABLES LIKE '%time_zone%'; 查) 先放总结: 修改方法: 1. 修改数据库时区 2. 在jdbc.url里加后缀 &serverTimezone=GMT%2B8 3. 代码里设置时区,给SimpleDateFormat.setTimeZone(...) 例外:new Date() 可以直接存为正确时间,其他

  • 浅谈为什么MySQL不推荐使用子查询和join

    做分页查询: 1.对于mysql,不推荐使用子查询和join是因为本身join的效率就是硬伤,一旦数据量很大效率就很难保证,强烈推荐分别根据索引单表取数据,然后在程序里面做join,merge数据. 2.子查询就更别用了,效率太差,执行子查询时,MYSQL需要创建临时表,查询完毕后再删除这些临时表,所以,子查询的速度会受到一定的影响,这里多了一个创建和销毁临时表的过程. 3.如果是JOIN的话,它是走嵌套查询的.小表驱动大表,且通过索引字段进行关联.如果表记录比较少的话,还是OK的.大的话业务逻

  • 浅谈swoole的作用与原理

    PHP 中的 Node ?Swoole 到底是什么? 我先从官方文档中引用下 Swoole 的定义: Swoole:面向生产环境的 PHP 异步网络通信引擎. 使 PHP 开发人员可以编写高性能.可拓展的异步并发 TCP.UDP.Unix Socket.HTTP,WebSocket 服务,而无需深入了解非阻塞 I/O 编程和初级 Linux 内核. Swoole 使用 C 语言编写,作为 PHP 的基本扩展存在.听起来可还行,是吧?用 PHP 来运行 HTTP 服务?用 PHP 实现 Webso

  • 浅谈Redis主从复制以及主从复制原理

    面临问题 1. 机器故障.我们部署到一台 Redis 服务器,当发生机器故障时,需要迁移到另外一台服务器并且要保证数据是同步的.而数据是最重要的,如果你不在乎,基本上也就不会使用 Redis 了. 2. 容量瓶颈.当我们有需求需要扩容 Redis 内存时,从 16G 的内存升到 64G,单机肯定是满足不了.当然,你可以重新买个 128G 的新机器. 解决办法 要实现分布式数据库的更大的存储容量和承受高并发访问量,我们会将原来集中式数据库的数据分别存储到其他多个网络节点上.Redis 为了解决这个

随机推荐