程序中添加事物处理,同表操作添加锁,这样可以防止MySQL出现脏数据.
前言:
①DEFAULT_STORAGE_ENGINE
为什么?简而言之,因为InnoDB是MySQL(包括Percona Server和MariaDB)最好的存储引擎 – 它支持事务,高并发,有着非常好的性能表现(当配置正确时).这里有详细的版本介绍为什么
这个是InnoDB最重要变量.实际上,如果你的主要存储引擎是InnoDB,那么对于你,这个变量对于MySQL是最重要的.
基本上,innodb_buffer_pool_size指定了MySQL应该分配给InnoDB缓冲池多少内存,InnoDB缓冲池用来存储缓存的数据,二级索引,脏数据(已经被更改但没有刷新到硬盘的数据)以及各种内部结构如自适应哈希索引.
当然,如果你有大量的大事务更改,那么,更改比默认innodb日志缓冲大小更大的值会对你的性能有一定的提高,但是你使用的是autocommit,或者你的事务更改小于几k,那还是保持默认的值吧.
默认下,innodb_flush_log_at_trx_commit设置为1表示InnoDB在每次事务提交后立即刷新同步数据到硬盘.如果你使用autocommit,那么你的每一个INSERT, UPDATE或DELETE语句都是一个事务提交.
同步是一个昂贵的操作(特别是当你没有写回缓存时),因为它涉及对硬盘的实际同步物理写入.所以如果可能,并不建议使用默认值.
* 0表示刷新到硬盘,但不同步(提交事务时没有实际的IO操作)
已经有大量的文档写到sync_binlog,以及它和innodb_flush_log_at_trx_commit的关系,下面我们来简单的介绍下：
a) 如果你的服务器没有设置从服务器,而且你不做备份,那么设置sync_binlog=0将对性能有好处.
b) 如果你有从服务器并且做备份,但你不介意当主服务器崩溃时在二进制日志丢失一些事件,那么为了更好的性能还是设置为sync_binlog=0.
c) 如果你有从服务器并且备份,你非常在意从服务器的一致性,以及能及时恢复到一个时间点(通过使用最新的一致性备份和二进制日志将数据库恢复到特定时间点的能力),那么你应该设置innodb_flush_log_at_trx_commit=1,并且需要认真考虑使用sync_binlog=1.
将innodb_flush_method设置为O_DIRECT以避免双重缓冲.唯一一种情况你不应该使用O_DIRECT是当你操作系统不支持时.但如果你运行的是Linux,使用O_DIRECT来激活直接IO.
简单地说,设置为innodb_flush_method=O_DIRECT.
你设置后观察会觉得性能提高不大,但在大多数高负载情况下,它应该会有不错的表现.
对了,不要指望这个设置能减少你单个查询的响应时间.这个是在高并发负载的服务器上才看得出区别.比如多个线程同时做许多事情.
InnoDB有一种方法来控制并行执行的线程数 – 我们称为并发控制机制.大部分是由innodb_thread_concurrency值来控制的.如果设置为0,并发控制就关闭了,所以呢InnoDB会立即处理所有进来的请求(尽可能多的).
下面介绍如何更改这个变量,在mysql命令行提示符执行：
这一项不得不提及,因为仍然有很多人没有添加这一项.你应该添加skip_name_resolve来避免连接时DNS解析.
大多数情况下你更改这个会没有什么感觉,因为大多数情况下DNS服务器解析会非常快.不过当DNS服务器失败时,它会出现在你服务器上出现"unauthenticated connections" ,而就是为什么所有的请求都突然开始慢下来了.
所以不要等到这种事情发生才更改.现在添加这个变量并且避免基于主机名的授权.
①.0.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX
* innodb_io_capacity：用来当刷新脏数据时,控制MySQL每秒执行的写IO量.
* innodb_io_capacity_max: 在压力下,控制当刷新脏数据时MySQL每秒执行的写IO量
首先,这与读取无关 – SELECT查询执行的操作.对于读操作,MySQL会尽最大可能处理并返回结果.至于写操作,MySQL在后台会循环刷新,在每一个循环会检查有多少数据需要刷新,并且不会用超过innodb_io_capacity指定的数来做刷新操作.这也包括更改缓冲区合并（在它们刷新到磁盘之前,更改缓冲区是辅助脏页存储的关键）.
第二,我需要解释一下什么叫"在压力下",MySQL中称为"紧急情况",是当MySQL在后台刷新时,它需要刷新一些数据为了让新的写操作进来.然后,MySQL会用到innodb_io_capacity_max.
那么,应该设置innodb_io_capacity和innodb_io_capacity_max为什么呢?
①.1.INNODB_STATS_ON_METADATA
两件事：
第一,它实际上没有在关闭时复制缓冲池内容到文件,仅仅是复制表空间ID和页面ID – 足够的信息来定位硬盘上的页面了.然后它就能以大量的顺序读非常快速的加载那些页面,而不是需要成千上万的小随机读.
第二,启动时是在后台加载内容,因为MySQL不需要等到缓冲池内容加载完成再开始接受请求(所以看起来不会有什么影响).
如果你运行着一个大量SELECT查询的MySQL服务器(并且已经尽可能优化),那么自适应哈希索引将下你的下一个瓶颈.自适应哈希索引是InnoDB内部维护的动态索引,可以提高最常用的查询模式的性能.这个特性可以重启服务器关闭,不过默认下在mysql的所有版本开启.
这个技术非常复杂,在大多数情况下它会对大多数类型的查询直到加速的作用.不过,当你有太多的查询往数据库,在某一个点上它会花过多的时间等待AHI锁和闩锁.
如果人认为查询缓存效果很好,肯定应该使用它.好吧,有时候是有用的.不过这个只在你在低负载时有用,特别是在低负载下大多数是读取,小量写或者没有.
如果你的MySQL服务器高负载动作,建议设置query_cache_size=0和query_cache_type=OFF,并重启服务器生效.那样Mysql就会停止在所有的查询使用查询缓存互斥锁.
表缓存用来存放目前已打开表的列表,当每一个表打开或关闭互斥体就被锁定 – 即使这是一个隐式临时表.使用多个分区绝对减少了潜在的争用.
欢迎做Java的工程师朋友们私信我资料免费获取免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）
其中覆盖了互联网的方方面面,期间碰到各种产品各种场景下的各种问题,很值得大家借鉴和学习,扩展自己的技术广度和知识面.
术式之后皆为逻辑,一切皆为需求和实现.希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别.
隔离级别的产生
在串型执行的条件下,数据修改的顺序是固定的、可预期的结果,但是并发执行的情况下,数据的修改是不可预期的,也不固定,为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果,由此产生了隔离级别.
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法.
READ UNCOMMITTED ? ? ? 未提交读,可以读取未提交的数据.READ COMMITTED ? ? ? ? 已提交读,对于锁定读(select with for update 或者 for share)、update 和 delete 语句, ? ? ? ? ? ? ? ? ? ? ? InnoDB 仅锁定索引记录,而不锁定它们之间的间隙,所以呢允许在锁定的记录旁边自由插入新记录. ? ? ? ? ? ? ? ? ? ? ? Gap locking 仅用于外键约束检查和重复键检查.REPEATABLE READ ? ? ? ?可重复读,事务中的一致性读取读取的是事务第一次读取所建立的快照.SERIALIZABLE ? ? ? ? ? 序列化
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL 语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例,数据范围全集包含：（数据范围不一定是连续的值,也可能是间隔的值组成）
① 数据已经填充了整个数据范围：（被完全填充的数据范围,不存在数据间隙）
如下：
在了解了数据全集的组成后,我们再来看看事务并发时,会带来的问题.
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题,主要包括以下几种情况.
① 范围内已有数据更改导致的：
更新丢失：当多个事务选择了同一行,然后基于最初选定的值更新该行时,
由于每个事物不知道其他事务的存在,最后的更新就会覆盖其他事务所做的更新；
脏读： 一个事务正在对一条记录做修改,这个事务完成并提交前,这条记录就处于不一致状态.
这时,另外一个事务也来读取同一条记录,如果不加控制,
第二个事务读取了这些"脏"数据,并据此做了进一步的处理,就会产生提交的数据依赖关系.
这种现象就叫"脏读".
不可重复读：一个事务在读取某些数据后的某个时间,再次读取以前读过的数据,
却发现其读出的数据已经发生了改变,或者某些记录已经被删除了.
这种现象就叫"不可重复读".
幻读：一个事务按相同的查询条件重新读取以前检索过的数据,
却发现其他事务插入了满足其查询条件的新数据,这种现象称为"幻读".
可以简单的认为满足条件的数据量变化了.
因为无控制的并发会带来一系列的问题,这些问题会导致无法满足我们所需要的结果.所以呢我们需要控制并发,以实现我们所期望的结果(隔离级别).
MySQL 隔离级别的实现
InnoDB 通过加锁的策略来支持这些隔离级别.
行锁包含：
Record Locks
索引记录锁,索引记录锁始终锁定索引记录,即使表中未定义索引,
这种情况下,InnoDB 创建一个隐藏的聚簇索引,并使用该索引进行记录锁定.
Gap Locks
间隙锁是索引记录之间的间隙上的锁,或者对第一条记录之前或者最后一条记录之后的锁.
间隙锁是性能和并发之间权衡的一部分.
对于无间隙的数据范围不需要间隙锁,因为没有间隙.
Next-Key Locks
索引记录上的记录锁和索引记录之前的 gap lock 的组合.
可能的next-key locks包括以下间隔,其中圆括号表示不包含间隔端点,方括号表示包含端点：
左右滑动进行查看
"上确界"伪记录的值高于索引中任何实际值.
上确界不是一个真正的索引记录,所以呢,实际上,这个 next-key 只锁定最大索引值之后的间隙.
基于此,当获取的数据范围中,数据已填充了所有的数据范围,那么此时是不存在间隙的,也就不需要 gap lock.
对于数据范围内存在间隙的,需要根据隔离级别确认是否对间隙加锁.
默认的 REPEATABLE READ 隔离级别,为了保证可重复读,除了对数据本身加锁以外,还需要对数据间隙加锁.
READ COMMITTED 已提交读,不匹配行的记录锁在 MySQL 评估了 where 条件后释放.
对于 update 语句,InnoDB 执行 "semi-consistent" 读取,这样它会将最新提交的版本返回到 MySQL,
以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配.
总结延展：
唯一索引存在唯一约束,所以变更后的数据若违反了唯一约束的原则,则会失败.
当 where 条件使用二级索引筛选数据时,会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时,都会等待锁.
行锁的增加是一行一行增加的,所以可能导致并发情况下死锁的发生.
例如,
在 session A 对符合条件的某聚簇索引加锁时,可能 session B 已持有该聚簇索引的 Record Locks,而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks.
session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引.
session A 通过索引 idA,session B通过索引 idB .
当 where 条件获取的数据无间隙时,无论隔离级别为 rc 或 rr,都不会存在间隙锁.
比如通过唯一索引获取到了已完全填充的数据范围,此时不需要间隙锁.
间隙锁的目的在于阻止数据插入间隙,所以无论是通过 insert 或 update 变更导致的间隙内数据的存在,都会被阻止.
rc 隔离级别模式下,查询和索引扫描将禁用 gap locking,此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）.
rr 模式下,为了防止幻读,会加上 Gap Locks.
事务中,SQL 开始则加锁,事务结束才释放锁.
就锁类型而言,应该有优化锁,锁升级等,例如rr模式未使用索引查询的情况下,是否可以直接升级为表锁.
就锁的应用场景而言,在回放场景中,如果确定事务可并发,则可以考虑不加锁,加快回放速度.
锁只是并发控制的一种粒度,只是一个很小的部分：
从不同场景下是否需要控制并发,(已知无交集且有序的数据的变更,MySQL 的 MTS 相同前置事务的多事务并发回放)
并发控制的粒度,(锁是一种逻辑粒度,可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化,(锁本身存在优化,如IX、IS类型的优化锁)
粒度加载的安全性能(如获取行锁前,先获取页锁,页锁在执行获取行锁操作后即释放,无论是否获取成功)等多个层次去思考并发这玩意.
MYSQL事务隔离级别的认识
在hibernate中如果要连续不间断的保存多个实体的实例,那么在我们保存第一个的时候,其实在数据库里是不存在数据的,即使用Session.flush()也无济于事,这到底是怎么回事呢?让我很是疑惑.......
在查阅了相关的资料后,原来是数据库对于事务的隔离级别的限制问题,而我原来的MYSQL数据库正好是不支持我上述操作的隔离级别.
①.、在MYSQL中查询事务隔离级别：
select @@tx_isolation;（tx其实就是transaction的缩写或者习惯缩写法）
我的结果是REPEATABLE-READ（即可重复读,稍后会引用专业结束文档）
set transaction isolation level 目标隔离级别;
这样在修改了隔离级别之后,在进行save()的时候,数据库中就会存在一些数据了,问题解决了.关于其他的数据库产品,思想都是一样的.
附加、官方的SQL事务隔离级别文档：
Read Uncommitted（读取未提交内容）
在该隔离级别,所有事务都可以看到其他未提交事务的执行结果.本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少.读取未提交的数据,也被称之为脏读（Dirty Read）.
Read Committed（读取提交内容）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）.它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变.这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read）,因为同一事务的其他实例在该实例处理其间可能会有新的commit,所以同一select可能返回不同结果.
Repeatable Read（可重读）
这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行.不过理论上,这会导致另一个棘手的问题：幻读 （Phantom Read）.简单的说,幻读指当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的"幻影" 行.InnoDB和Falcon存储引擎通过多版本并发控制（MVCC,Multiversion Concurrency Control）机制解决了该问题.
Serializable（可串行化）
这是最高的隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决幻读问题.简言之,它是在每个读的数据行上加上共享锁.在这个级别,可能导致大量的超时现象和锁竞争.
mysql 乐观锁怎么解决幻读
由于事务的并发执行,带来以下一些著名的问题：
(1)更新丢失（LostUpdate）：当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题－－最后的更新覆盖了由其他事务所做的更新.
以上就是土嘎嘎小编为大家整理的mysql脏数据怎么处理相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！