首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如果没有并发使用锁,那么锁是否会产生开销?

如果没有并发使用锁,锁不会产生开销。锁是用于控制并发访问共享资源的机制,当多个线程同时访问临界区代码时,锁可以确保同一时间只有一个线程可以进入临界区,避免数据竞争和并发错误。因此,在单线程或者没有竞争的情况下,不需要使用锁来保护共享资源,也就不会产生额外的开销。

但是需要注意的是,锁的使用是为了解决并发访问的问题,而不是为了减少开销。在并发场景下,锁会引入一定的开销,包括上锁和释放锁的开销,以及等待锁的线程消耗的资源。因此,在设计并发系统时,需要权衡锁的使用,避免过度的锁竞争导致性能下降。可以通过减小锁的粒度、采用更细粒度的锁、使用无锁数据结构等方式来降低锁的开销。

腾讯云提供了一系列云原生产品和服务,包括容器服务、Kubernetes引擎、云原生数据库、函数计算等,用于支持云原生应用的开发和部署。这些产品和服务可以帮助用户构建弹性、可扩展、高可用的云原生架构。您可以通过以下链接了解更多腾讯云相关产品和服务:

  1. 腾讯云容器服务:提供了基于Kubernetes的容器部署与管理服务,支持容器编排、弹性伸缩、自动修复等功能。详细信息请参考腾讯云容器服务
  2. 腾讯云无服务器云函数(SCF):无服务器云函数是一种事件驱动的计算服务,无需管理服务器,支持自动扩缩容、按需付费等特性。详细信息请参考腾讯云无服务器云函数
  3. 腾讯云原生数据库(TDSQL):基于Kubernetes的云原生数据库服务,提供高可用、可扩展的数据库解决方案,支持MySQL、PostgreSQL等主流数据库。详细信息请参考腾讯云原生数据库

请注意,以上链接仅为示例,具体产品选择应根据实际需求进行评估和选择。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

MySQL的锁机制详解

一旦写数据的任务没有完成,数据是不能被其他任务读取的,这对并发操作有较大的影响。 意向锁:innoDB为了支持多粒度的锁,即允许行级锁和表级锁共存,而引入意向锁。...意向锁是指未来的某个时刻,事务可能要加共享/排他锁,先提前声明一个意向。这样如果有人尝试对全表进行修改,就不需要判断表中的数据是否被加锁了,只需要通过等待意向互斥锁被释放就行了。...记录锁总是会锁住索引记录,如果innoDB存储引擎表 在建立的时候没有设置任何一个索引,那么innoDB存储引擎会使用隐式的主键来进行锁定。...如果系统并发量非常大,悲观锁会带来非常大的性能问题,选择使用乐观锁,现在大部分应用属于乐观锁 悲观锁:悲观的假定大概率会发生并发更新冲突,访问,处理数据前就加排他锁,在整个数据处理过程中锁定数据,事务提交或回滚后才释放锁...缺点:     (a)在效率方面,处理加锁的机制会让数据库产生额外的开销,还有增加产生死锁的机会;     (b) 在只读型事务处理中由于不会产生冲突,也没必要使用锁,这样做只能增加系统负载;还有会降低了并行性

35410

互斥锁、自旋锁、读写锁、悲观锁、乐观锁的应用场景

如何用好锁,是程序员的基本素养之一。 高并发的场景下,如果选对了合适的锁,则会大大提高系统的性能,否则性能会降低。 所以,知道各种锁的开销,以及应用场景是很有必要的。...如果选择了错误的锁,那么在一些高并发的场景下,可能会降低系统的性能,这样用户体验就会非常差了。...如下图: 读优先锁对于读线程并发性更好,但也不是没有问题。 我们试想一下,如果一直有读线程获取读锁,那么写线程将永远获取不到写锁,这就造成了写线程「饥饿」的现象。...如果我们明确知道被锁住的代码的执行时间很短,那我们应该选择开销比较小的自旋锁,因为自旋锁加锁失败时,并不会主动产生线程切换,而是一直忙等待,直到获取到锁,那么如果被锁住的代码执行时间很短,那这个忙等待的时间相对应也很短...相反的,如果并发访问共享资源时,冲突概率非常低的话,就可以使用乐观锁,它的工作方式是,在访问共享资源时,不用先加锁,修改完共享资源后,再验证这段时间内有没有发生冲突,如果没有其他线程在修改资源,那么操作完成

1.5K40
  • 详解mysql的锁机制

    一旦写数据的任务没有完成,数据是不能被其他任务读取的,这对并发操作有较大的影响。 意向锁:innoDB为了支持多粒度的锁,即允许行级锁和表级锁共存,而引入意向锁。...意向锁是指未来的某个时刻,事务可能要加共享/排他锁,先提前声明一个意向。这样如果有人尝试对全表进行修改,就不需要判断表中的数据是否被加锁了,只需要通过等待意向互斥锁被释放就行了。...记录锁总是会锁住索引记录,如果innoDB存储引擎表 在建立的时候没有设置任何一个索引,那么innoDB存储引擎会使用隐式的主键来进行锁定。...如果系统并发量非常大,悲观锁会带来非常大的性能问题,选择使用乐观锁,现在大部分应用属于乐观锁 悲观锁:悲观的假定大概率会发生并发更新冲突,访问,处理数据前就加排他锁,在整个数据处理过程中锁定数据,事务提交或回滚后才释放锁...缺点: (a)在效率方面,处理加锁的机制会让数据库产生额外的开销,还有增加产生死锁的机会; (b) 在只读型事务处理中由于不会产生冲突,也没必要使用锁,这样做只能增加系统负载;还有会降低了并行性,一个事务如果锁定了某行数据

    62200

    面试官:你说说互斥锁、自旋锁、读写锁、悲观锁、乐观锁的应用场景

    高并发的场景下,如果选对了合适的锁,则会大大提高系统的性能,否则性能会降低。 所以,知道各种锁的开销,以及应用场景是很有必要的。...如果选择了错误的锁,那么在一些高并发的场景下,可能会降低系统的性能,这样用户体验就会非常差了。...如下图: 读优先锁对于读线程并发性更好,但也不是没有问题。我们试想一下,如果一直有读线程获取读锁,那么写线程将永远获取不到写锁,这就造成了写线程「饥饿」的现象。...如果我们明确知道被锁住的代码的执行时间很短,那我们应该选择开销比较小的自旋锁,因为自旋锁加锁失败时,并不会主动产生线程切换,而是一直忙等待,直到获取到锁,那么如果被锁住的代码执行时间很短,那这个忙等待的时间相对应也很短...相反的,如果并发访问共享资源时,冲突概率非常低的话,就可以使用乐观锁,它的工作方式是,在访问共享资源时,不用先加锁,修改完共享资源后,再验证这段时间内有没有发生冲突,如果没有其他线程在修改资源,那么操作完成

    3.2K51

    mysql的乐观锁使用_java悲观锁乐观锁定义

    但是在效率方面,处理加锁的机制会让数据库产生额外的开销,还有增加产生死锁的机会;另外,在只读型事务处理中由于不会产生冲突,也没必要使用锁,这样做只能增加系统负载;还有会降低了并行性,一个事务如果锁定了某行数据...,我们可以从下面三个因素来考虑: 响应速度: 如果Dao层需要非常高的响应速度,尤其是读多写少的场景下,那我们就可以采用乐观锁方案,降低数据库锁的开销,提供并发量 冲突频率: 如果冲突频率非常高,那么我们就可以采用悲观锁...,保证成功率;毕竟如果冲突频率大,乐观锁会需要多次重试才能成功,代价可能会大大增加 重试代价: 如果重试代价大,比如说重试过程的代码执行非常耗时,那么此时我就不建议使用乐观锁了,还不如直接上悲观锁来了爽快...所以我们知道: 在读多写少,CAS竞争没这么激烈的时候,我们可以采用乐观锁策略,降低数据库加锁的开销,提高数据库并发响应 在写多读少的场景下,因为会产生大量的CAS竞争,且重试成本比较高的情况下,我们就不建议再采用乐观锁策略了...,没有获得锁的事务只能等待其他事务释放锁;所以可以解决脏读,幻读,不可重复读,第一类更新丢失,第二类更新丢失的问题 乐观并发控制(OCC)是一种用来解决写-写冲突的无锁并发控制,认为事务间争用没有那么多

    76920

    再谈mysql锁机制及原理—锁的诠释

    举个例子,如果表中记录1亿,事务A把其中有几条记录上了行锁了,这时事务B需要给这个表加表级锁,如果没有意向锁的话,那就要去表中查找这一亿条记录是否上锁了。...如果存在意向锁,那么假如事务A在更新一条记录之前,先加意向锁,再加X锁,事务B先检查该表上是否存在意向锁,存在的意向锁是否与自己准备加的锁冲突,如果有冲突,则等待直到事务A释放,而无须逐条记录去检测。...Record Lock总是会去锁住索引记录,如果InnoDB存储引擎表在建立的时候没有设置任何一个索引,那么这时InnoDB存储引擎会使用隐式的主键来进行锁定。...在业务繁忙的情况下,如果事务没有及时的commit或者rollback 可能会造成其他事务长时间的等待,从而影响数据库的并发使用效率。...在应用中,如果不同的程序会并发存取多个表,应尽量约定以相同的顺序来访问表,这样可以大大降低产生死锁的机会 通过SELECT ...

    1.5K01

    Java 多线程系列Ⅴ

    使用重量级锁,那么其他线程会等待持有资源的线程释放该锁,然后才能获取该资源并进行操作。这会造成线程的上下文切换并增加系统的开销。...使用轻量级锁,则其他线程会尝试获取该资源的锁并设置标记位,如果成功则继续执行操作;如果失败则会自旋等待,直到持有锁的线程释放该锁为止。这可以减少系统的开销并提高程序的执行效率。...自旋锁在尝试获取锁时,会一直循环检查锁是否可用,直到获取到锁为止。如果锁已经被其他线程持有,则当前线程会一直循环检查该锁的标记位,直到获取到锁或者线程被阻塞为止。...使用自旋锁,那么其他线程会一直循环检查该资源的标记位,直到获取到锁为止。这会浪费CPU资源并且会占用较多的CPU缓存资源。...使用互斥锁,那么银行工作人员和客户会相互等待对方释放互斥锁,这会导致死锁等问题。 使用读写锁,银行工作人员可以获取独占锁并修改账户余额,而客户可以同时获取共享锁并查询账户余额。

    17210

    MySQL死锁产生原因和解决方法

    表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。...根据死锁预防策略,在持有页面锁,加行锁的时候,如果行锁需要等待。则释放页面锁,然后等待行锁。此时,行锁获取没有任何锁保护,因此加上行锁之后,记录可能已经被并发修改。...因此,此时要重新加回页面锁,重新判断记录的状态,重新在页面锁的保护下,对记录加锁。如果此时记录未被并发修改,那么第二次加锁能够很快完成,因为已经持有了相同模式的锁。...但是,如果记录已经被并发修改,那么,就有可能导致本文前面提到的死锁问题。 以上的InnoDB死锁预防处理逻辑,对应的函数,是row0sel.c::row_search_for_mysql()。...此类死锁,产生的几个前提: Delete操作,针对的是唯一索引上的等值查询的删除;(范围下的删除,也会产生死锁,但是死锁的场景,跟本文分析的场景,有所不同) 至少有3个(或以上)的并发删除操作; 并发删除操作

    5.8K40

    MySQL 中的 锁机制 详解

    如果加锁失败,说明该记录正在被修改,那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。 如果成功加锁,那么就可以对记录做修改,事务完成后就会解锁了。...但是在效率方面,处理加锁的机制会让数据库产生额外的开销,还有增加产生死锁的机会;另外,在只读型事务处理中由于不会产生冲突,也没必要使用锁,这样做只能增加系统负载;还有会降低了并行性,一个事务如果锁定了某行数据...它假设多用户并发的事务在处理时不会彼此互相影响,各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前,每个事务会先检查在该事务读取数据后,有没有其他事务又修改了该数据。...即便在条件中使用了索引字段,但是否使用索引来检索数据是由 MySQL 通过判断不同 执行计划的代价来决定的,如果 MySQL 认为全表扫 效率更高,比如对一些很小的表,它 就不会使用索引,这种情况下 InnoDB...因此,在分析锁冲突时, 别忘了检查 SQL 的执行计划,以确认是否真正使用了索引。

    48120

    MySQL 死锁产生原因和解决方法

    表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。...根据死锁预防策略,在持有页面锁,加行锁的时候,如果行锁需要等待。则释放页面锁,然后等待行锁。此时,行锁获取没有任何锁保护,因此加上行锁之后,记录可能已经被并发修改。...因此,此时要重新加回页面锁,重新判断记录的状态,重新在页面锁的保护下,对记录加锁。如果此时记录未被并发修改,那么第二次加锁能够很快完成,因为已经持有了相同模式的锁。...但是,如果记录已经被并发修改,那么,就有可能导致本文前面提到的死锁问题。 以上的 InnoDB 死锁预防处理逻辑,对应的函数,是 row0sel.c::row_search_for_mysql ()。...此类死锁,产生的几个前提: Delete 操作,针对的是唯一索引上的等值查询的删除;(范围下的删除,也会产生死锁,但是死锁的场景,跟本文分析的场景,有所不同) 至少有 3 个 (或以上) 的并发删除操作

    84761

    MySQL的并发控制 一文读懂!

    01 并发控制 无论何时,只要有多个查询需要在同一时刻修改数据,都会产生并发控制的问题 本文的目的是讨论MySQL在两个层面的并发控制:服务器层与存储引擎层 例如:以Unix系统的email box...但如果 某个客户正在读取邮箱,同时另外一个用户试图删除编号为25的邮件, 会产生什么结果?结论是不确定,读的客户可能会报错退出,也可能读取到不一致的邮箱数据。...锁的各种操作,包括获得锁、检查锁是否已经解除、释放锁等,都会增加系统的开销。...如果系统花费大量的时间来管理锁,而不是存取数据,那么系统的性能可能会因此受到影响 所谓的锁策略,就是在锁的开销和数据的安全性之间寻求平衡,这种平衡当然也会影响到性能。...例如,服务器会为诸如ALTER TABLE之类的语句使用表锁,而忽略存储引擎的锁机制 ★ 行级锁(row lock) 行级锁可以最大程度地支持并发处理(同时也带来了最大的锁开销) 众所周知,在InnoDB

    34020

    我通过六个 MySQL 死锁案例,终于理解了死锁的原因

    生活中,最常见的案例之一,十字路口没有红绿灯,到了十字路口相互不让,最后,整个马路瘫痪,在我们技术层面称之为死锁。 产生死锁的必要条件 1. 互斥条件:一个资源每次只能被一个线程使用 2....表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。...根据死锁预防策略,在持有页面锁,加行锁的时候,如果行锁需要等待。则释放页面锁,然后等待行锁。此时,行锁获取没有任何锁保护,因此加上行锁之后,记录可能已经被并发修改。...因此,此时要重新加回页面锁,重新判断记录的状态,重新在页面锁的保护下,对记录加锁。如果此时记录未被并发修改,那么第二次加锁能够很快完成,因为已经持有了相同模式的锁。...此类死锁,产生的几个前提: Delete操作,针对的是唯一索引上的等值查询的删除;(范围下的删除,也会产生死锁,但是死锁的场景,跟本文分析的场景,有所不同) 至少有3个(或以上)的并发删除操作; 并发删除操作

    2.1K32

    这六个 MySQL 死锁案例,能让你理解死锁的原因!

    行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。...根据死锁预防策略,在持有页面锁,加行锁的时候,如果行锁需要等待。则释放页面锁,然后等待行锁。此时,行锁获取没有任何锁保护,因此加上行锁之后,记录可能已经被并发修改。...因此,此时要重新加回页面锁,重新判断记录的状态,重新在页面锁的保护下,对记录加锁。如果此时记录未被并发修改,那么第二次加锁能够很快完成,因为已经持有了相同模式的锁。...但是,如果记录已经被并发修改,那么,就有可能导致本文前面提到的死锁问题。 以上的InnoDB死锁预防处理逻辑,对应的函数,是row0sel.c::row_search_for_mysql()。...此类死锁,产生的几个前提: Delete操作,针对的是唯一索引上的等值查询的删除;(范围下的删除,也会产生死锁,但是死锁的场景,跟本文分析的场景,有所不同) 至少有3个(或以上)的并发删除操作; 并发删除操作

    45710

    mysql数据库常见锁机制

    特点 开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。..., 默认为行级锁 ---- Innodb 中的行锁与表锁 在 Innodb 引擎中既支持行锁也支持表锁,那么什么时候会锁住整张表,什么时候或只锁住一行呢?...即便在条件中使用了索引字段, 但是否使用索引来检索数据是由 MySQL 通过判断不同 执行计划的代价来决定的, 如果 MySQL 认为全表扫 效率更高, 比如对一些很小的表, 它 就不会使用索引, 这种情况下...因此, 在分析锁冲突时, 别忘了检查 SQL 的执行计划, 以确认是否真正使用了索引。...---- 4如何防止死锁 有多种方法可以避免死锁,这里只介绍常见的三种 1、如果不同程序会并发存取多个表,尽量约定以相同的顺序访问表,可以大大降低死锁机会。

    1.9K90

    这六个 MySQL 死锁案例,能让你理解死锁的原因!

    行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。...根据死锁预防策略,在持有页面锁,加行锁的时候,如果行锁需要等待。则释放页面锁,然后等待行锁。此时,行锁获取没有任何锁保护,因此加上行锁之后,记录可能已经被并发修改。...因此,此时要重新加回页面锁,重新判断记录的状态,重新在页面锁的保护下,对记录加锁。如果此时记录未被并发修改,那么第二次加锁能够很快完成,因为已经持有了相同模式的锁。...但是,如果记录已经被并发修改,那么,就有可能导致本文前面提到的死锁问题。 以上的InnoDB死锁预防处理逻辑,对应的函数,是row0sel.c::row_search_for_mysql()。...此类死锁,产生的几个前提: Delete操作,针对的是唯一索引上的等值查询的删除;(范围下的删除,也会产生死锁,但是死锁的场景,跟本文分析的场景,有所不同) 至少有3个(或以上)的并发删除操作; 并发删除操作

    97440

    非阻塞同步机制和CAS

    使用锁虽然可以保证对资源的一致性访问,但是在挂起和恢复线程的执行过程中存在非常大的开销,如果锁上面存在着大量的竞争,那么有可能调度开销比实际工作开销还要高。...悲观锁和乐观锁 我们知道独占锁是一个悲观锁,悲观锁的意思就是假设最坏的情况,如果你不锁定该资源,那么就有其他的线程会修改该资源。悲观锁虽然可以保证任务的顺利执行,但是效率不高。...乐观锁就是假设其他的线程不会更改要处理的资源,但是我们在更新资源的时候需要判断该资源是否被别的线程所更改。如果被更改那么更新失败,我们可以重试,如果没有被更改,那么更新成功。...使用乐观锁的前提是假设大多数时间系统对资源的更新是不会产生冲突的。 乐观锁的原子性比较和更新操作,一般都是由底层的硬件支持的。...无论是否写入成功,都会返回V。翻译过来就是“我认为V现在的值是A,如果是那么将V的值更新为B,否则不修改V的值,并告诉我现在V的值是多少。”

    48350

    Java 中的锁 (总结)

    它假设多用户并发的事务在处理时不会彼此互相影响,各事务能够在不产生 “锁” 的情况下处理各自影响的那部分数据。在提交数据更新之前,每个事务会先检查在该事务上次读取数据后,有没有其他事务又修改了该数据。...一旦获取了自旋锁,线程会一直保持该锁,直至显式释放自旋锁。 适用场景 自旋锁避免了进程上下文的调度开销,因此对于线程只会阻塞很短时间的场合是有效的。...读写分离控制 ReadWriteLock 自旋锁 反复检查锁变量是否可用,多多等待一会。避免线程阻塞和再唤醒的调度开销。 对于线程只会阻塞很短时间的场合 避免额外的调度开销 3....,则使用重量级锁,没有获取到锁的线程阻塞挂起,直到持有锁的线程执行完同步块唤醒他们; 偏向锁是在无锁争用的情况下使用的,也就是同步开在当前线程没有执行完之前,没有其它线程会执行该同步块,一旦有了第二个线程的争用...,偏向锁就会升级为轻量级锁,如果轻量级锁自旋到达阈值后,没有获取到锁,就会升级为重量级锁; 如果线程争用激烈,那么应该禁用偏向锁。

    51430

    一篇文章弄懂MySQL锁机制

    ,专门控制其并发插入的行为 concurrent_insert=0时,不允许并发插入 concurrent_insert=1时,如果MyISAM表中没有空洞(即表的中间没有被删除的行),其允许在一个进程读表的同事...如果一个事务请求的锁模式与当前锁兼容,InnoDB就请求的锁授予该事务; 3、行级锁(Record lock)导致的死锁 为什么会产生死锁?...3、如何避免死锁: 用SHOW INNODB STATUS命令来确定最后一个死锁产生的原因和改进措施 (1)如果不同程序会并发存取多个表,尽量约定以相同的顺序访问表,可以大大降低死锁机会。...缺点: (a)在效率方面,处理加锁的机制会让数据库产生额外的开销,还有增加产生死锁的机会; (b) 在只读型事务处理中由于不会产生冲突,也没必要使用锁,这样做只能增加系统负载;还有会降低了并行性,一个事务如果锁定了某行数据...如果系统并发量非常大,悲观锁会带来非常大的性能问题,选择使用乐观锁,现在大部分应用属于乐观锁 版本控制机制: 每一行数据多一个字段version,每次更新数据对应版本号+1, 原理:读出数据,将版本号一同读出

    72130

    面试命中率 90% 的点 :MySQL 锁

    ~ 一、对MySQL的锁的了解 当数据库有并发事务的时候,可能会产生数据的不一致,这时候需要一些机制来保证访问的次序,锁机制就是这样的一个机制。...ID 是有索引键的列,如果 ID不是索引键那么InnoDB将完成表锁,并发将无从谈起 六、InnoDB存储引擎的锁的算法有三种 1.Record lock:单个行记录上的锁 2.Gap lock:间隙锁...常见的解决死锁的方法 1、如果不同程序会并发存取多个表,尽量约定以相同的顺序访问表,可以大大降低死锁机会。...2、在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁产生概率; 3、对于非常容易产生死锁的业务部分,可以尝试使用升级锁定颗粒度,通过表级锁定来减少死锁产生的概率; 如果业务处理不好可以用分布式事务锁或者使用乐观锁...但如果是多写的情况,一般会经常产生冲突,这就会导致上层应用会不断的进行Retry,这样反倒是降低了性能,所以一般多写的场景下用悲观锁就比较合适。

    56830

    对MySQL的锁了解吗

    当数据库有并发事务的时候,可能会产生数据的不一致,这时候需要一些机制来保证访问的次序,锁机制就是这样的一个机制。...并且 id 是有索引键的列,如果 id 不是索引键那么InnoDB将完成表锁,并发将无从谈起 InnoDB存储引擎的锁的算法有三种 Record lock:单个行记录上的锁 Gap lock:间隙锁,锁定一个范围...常见的解决死锁的方法 1、如果不同程序会并发存取多个表,尽量约定以相同的顺序访问表,可以大大降低死锁机会。...2、在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁产生概率; 3、对于非常容易产生死锁的业务部分,可以尝试使用升级锁定颗粒度,通过表级锁定来减少死锁产生的概率; 如果业务处理不好可以用分布式事务锁或者使用乐观锁...但如果是多写的情况,一般会经常产生冲突,这就会导致上层应用会不断的进行retry,这样反倒是降低了性能,所以一般多写的场景下用悲观锁就比较合适。

    1.2K10
    领券