数据库的并发 *** 作可能带来哪些问题 丢失更新 死锁 违反唯一性约束

数据库中常见的并发 *** 作所带来的一致性问题包括：丢失的修改、不可重复读、读脏数据、幻影读（幻影读在一些资料中往往与不可重复读归为一类）。

丢失修改

下面先来看一个例子，说明并发 *** 作带来的数据的不一致性问题。

考虑飞机订票系统中的一个活动序列:

甲售票点（甲事务）读出某航班的机票余额A,设A=16

乙售票点（乙事务）读出同一航班的机票余额A,也为16

甲售票点卖出一张机票,修改余额A←A-1所以A为15,把A写回数据库

乙售票点也卖出一张机票,修改余额A←A-1所以A为15,把A写回数据库

结果明明卖出两张机票，数据库中机票余额只减少1。

归纳起来就是：两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。前文（214数据删除与更新）中提到的问题及解决办法往往是针对此类并发问题的。但仍然有几类问题通过上面的方法解决不了，那就是：

不可重复读

不可重复读是指事务T1读取数据后，事务T2执行更新 *** 作，使T1无法再现前一次读取结果。具体地讲，不可重复读包括三种情况：

事务T1读取某一数据后，事务T2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。例如，T1读取B=100进行运算，T2读取同一数据B，对其进行修改后将B=200写回数据库。T1为了对读取值校对重读B，B已为200，与第一次读取值不一致。

事务T1按一定条件从数据库中读取了某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神密地消失了。

事务T1按一定条件从数据库中读取某些数据记录后，事务T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。（这也叫做幻影读）

读"脏"数据

读"脏"数据是指事务T1修改某一数据，并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤消，这时T1已修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致，则T2读到的数据就为"脏"数据，即不正确的数据。

产生上述三类数据不一致性的主要原因是并发 *** 作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发 *** 作，使一个用户事务的执行不受其它事务的干扰，从而避免造成数据的不一致性。

并发一致性问题的解决办法

封锁（Locking）

封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表

使用SELECT LAST_INSERT_ID() 函数就可以，因为LAST_INSERT_ID是基于Connection的，只要每个线程都使用独立的 Connection对象，LAST_INSERT_ID函数将返回该Connection对AUTO_INCREMENT列最新的insert or update *** 作生成的第一个record的ID。这个值不能被其它客户端（Connection）影响，保证了你能够找回自己的 ID 而不用担心其它客户端的活动，而且不需要加锁。使用单INSERT语句插入多条记录, LAST_INSERT_ID返回一个列表。

1用一个标识，在选择那张票的时候先用(Update 表 set 票flag=‘占用了！’ where 票flag=‘未占用’ and )这样是保险的，不可能存在并发问题，这就牵扯到sql锁机制问题了，你可以测试一下，其实sql中update是先查询出然后删除再添加，但由于使用了update，过程中就自动加锁了，很方便吧2加锁。Microsoft® SQL Server™ 2000 使用锁定确保事务完整性和数据库一致性。锁定可以防止用户读取正在由其他用户更改的数据，并可以防止多个用户同时更改相同数据。如果不使用锁定，则数据库中的数据可能在逻辑上不正确，并且对数据的查询可能会产生意想不到的结果。虽然 SQL Server 自动强制锁定，但可以通过了解锁定并在应用程序中自定义锁定来设计更有效的应用程序。

1 事实上，交易不帮你在这里多除非你想有运行在多个>

主要通过架构设计来减少高并发对数据库的压力；

比如 在数据库和应用程序之间，增加 DAL层，通过代理，连接池等，保证数据库与业务程序由一定的缓冲和关系梳理；

在数据库前面，加一个缓存层，让大部分数据访问，都直接在缓存层获取数据，不用访问到后端的MySQL数据库；

世界是矛盾的。串行方式工作效率低，所以人们想到了并发方式，但是所有的并发都会在某种情况下带来问题。也就是所谓的并发问题。例如，在数据库中有第一类丢失更新问题，脏读问题、不可重复读问题、虚读问题、第二类丢失更新问题。所以，需要我们在开发程序的时候需要处理某些并发带来的问题。也就是说使用并发 *** 作，但是不能有问题。通常采用总体并发，局部串行的方式。

mysql数据库超过并发量会pengding mysql数据库超过并发量会

主要是针对数据量很大，和并发访问量高的时候

经验一:

在开发过程中，我们经常会写

SELECT FROM table WHERE 1 ORDER BY xxx DESC LIMIT 0,10

这样的语句用来分页

在有完美索引的情况 对xxx建立索引

前面几页会很快，但如果数据量达到100万级以后，我们查询最后一页

SELECT FROM table WHERE 1 ORDER BY xxx DESC LIMIT 999990,10

这句执行就会很慢，同时有多人访问服务器就会掉 (这里不考虑缓存，因为内容更新太快，有时候缓存了达不到数据的更新的要求)

但如果我们把

SELECT FROM table WHERE 1 ORDER BY xxx DESC LIMIT 999990,10

换成

SELECT FROM table WHERE 1 ORDER BY xxx ASC LIMIT 0,10

这两个的MYSQL执行时间可是大大的不一样 当然要注意把这样取出来的结果用PHP重新排序一下

取得的一样是最后一页的数据，当然最中间的两页有部分数据一样

这时候最慢的只是最中间的部分，相对而言，访问最中间的人还是很少的

经验二:

例如论坛帖子列表的显示:

一般是SELECT FROM table ORDER BY is_top DESC ,post_time DESC LIMIT 0,10这样的分页

两个order by 的执行是非常慢的，哪怕你有再好的索引，

我们的处理办法是 把is_top的数据CACHE住，毕竟is_top的数据量有限，更新这个缓存也容易

然后SQL一样是SELECT FROM table ORDER BY post_time DESC LIMIT {$num},{$num2}

注意这个$num2 是减掉is_top的数量后的一个值,$num是is_top的数量

当然还要考虑is_top的数据量是不是有好几页,当前页的值是不是都在cache里面

经验三:

SELECT FROM table ORDER BY RAND() LIMIT 100 这个ORDER BY RAND() 是非常慢的 能不用尽量不要用

处理办法是

1用PHP生成数组后，然后用SELECT FROM table WHERE id IN() WHERE IN 也比这个order by rand()快的多

2如果数量信息不太重多，就用SELECT FROM table WHERE 1 LIMIT 500 多取点数据，然后用php 处理数组

以上就是关于数据库的并发 *** 作可能带来哪些问题 丢失更新 死锁 违反唯一性约束全部的内容，包括:数据库的并发 *** 作可能带来哪些问题 丢失更新 死锁 违反唯一性约束、高并发性的数据库 *** 作-Mysql、怎么解决数据库并发的问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！