前几天有粉丝和我聊到他找工作面试大厂时被问的问题，因为现在疫情期间，找工作也特别难找。他说面试的题目也比较难，都偏向于一两年的工作经验的面试题。
在MySQL中对于并发，锁问题总是会有很多值得讨论的地方，但是通常来说，要模拟这些锁或者一些锁的问题需要花点功夫，比如创建多个表，创建大量的数据，然后像调试钟表的秒针一样，让问题刚好复现在哪个时间点上。如果换一个角度，单表来模拟这类而是可以吗，其实是可行的。 今天简单通过单表的测试模拟死锁，事务中的隐式提交（其实可以理解是个bug),间歇锁。 初始化数据 首先的准备工作就是初始化数据，我们创建一个表test,事务隔离级别为默认的RR。 建表语句： create table test( id int
上篇文章我们简单的了解了一大堆锁相关的概念，然后只是简单的演示了一下 InnoDB 和 MyISAM 之间 表锁 与 行锁 的差别。相信大家还是意犹未尽的，今天我们就来用代码说话，实际地操作一下，看看如何进行手动的加 表锁 与 行锁 ，并进行一些相关的实验测试。
在上篇文章，我们聊了「MySQL 啥时候会用表锁，啥时候用行锁」这个问题。在文章中，我们还留了一个问题，即：如果查询或更新时的数据特别多，是否从行锁会升级为表锁？此外，还有朋友留言说到：不同的隔离级别可能会用不同的锁，可以结合隔离级别来聊聊。
在多线程高并发场景下，为了保证资源的线程安全问题，jdk为我们提供了synchronized关键字和 ReentrantLock可重入锁，但是它们只能保证一个jvm内的线程安全。在分布式集群、微服务、云原生横行的当下，如何保证不同进程、不同服务、不同机器的线程安全问题，jdk并没有给我们提供既有的解决方案。此时，我们就必须借助于相关技术手动实现了。目前主流的实现有三种方式： 1. 基于mysql关系型实现 2. 基于redis非关系型数据实现 3. 基于zookeeper实现
升级完成之后，放业务请求进来，没到一分钟就开始出现慢查询，然后，慢查询越来越多，业务 SQL 出现堆积。
本文介绍了TXSQL项目，主要关注于解决金融、运营商等行业的核心系统对分布式数据库的依赖问题，以及满足业务对数据库的高可用、高弹性、高安全等需求。TXSQL在数据一致性、高可用、高性能等方面具有优势，能够有效地支持分布式数据库的部署要求。同时，TXSQL还提供了丰富的数据复制和数据迁移工具，以及数据恢复和故障转移功能，以满足高安全业务场景的需求。此外，TXSQL还提供了基于云平台的运维管控和运维工具，以实现对分布式数据库的高效运维。
出现这个问题感觉还是挺疑惑的，因为测试环境已经稳定运行了几个月的时间，一直没有出现过mysql事务锁的问题，于是开始着手查问题。
本文介绍了TXSQL项目，旨在解决分布式系统中数据一致性和数据可用性的问题，通过自研的基于Paxos协议的一致性算法，配合多种数据复制方式，确保数据的一致性、可靠性、容错性，同时提供了丰富的数据复制方式，并支持跨园区、跨可用区、跨数据中心的部署，并支持多种隔离级别和审计日志，以满足不同业务的需求，同时提供了一些基础监控和运维工具，以确保服务的稳定和可靠，可以作为企业数据库服务的一个基础组件，支持企业的业务运行和发展。
当我们使用如上所述的语法的时候，这两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时，都必须等待其它事务数据被提交(Commit)后才会执行。
REPEATABLE READ是InnoDB的默认隔离级别。MySQL对它有如下的支持：
MySQL 的主从同步应该是被各个 DBA 熟知的技术了，从 MySQL 3.23.15 开始一直迭代改进到 8.0 版本。经过这么多年的改进，目前 8.0 提供的复制技术是最新的 WriteSet 机制，这个功能也被合并到了 5.7.21 版本，解决了 5.7 并行复制的一些问题。
作者简介 姜宇祥，2012年加入携程，10年数据库核心代码开发经验，相关开发涉及达梦，MySQL数据库。现致力于携程MySQL的底层研发，为特殊问题定位和处理提供技术支持。 前言：希望通过本文，使MySQL5.7.18的使用者知晓分区表使用中存在的陷阱，避免在该版本上继续踩坑。同时通过对源码的分享，升级MySQL5.7.18时分区表性能下降的根本原因，向MySQL源码爱好者展示分区表实现中锁的运用。 问题描述 MySQL 5.7版本中，性能相关的改进非常多。包括临时表相关的性能改进，连接建立速度的优化和
今天遇到一个高并发悲观锁的问题，活跃连接堆积恶性循环最后DB卡死了。做下测试总结。看看这类SQL能扛多少，以后遇到问题心里也有底了。这是出问题前的截图，QPS继续涨连接就开始堆积了，SQL还是这些频率高了。还有一点TOP1的SQL有热点的行for update。
今天，我们通过模拟案例以及原理分析，去弄清楚MySQL中DDL的风险，以及如何避免事故发生。
随着并发量的不断增加，单机的服务迟早要向多节点或者微服务进化，这时候原来单机模式下使用的synchronized或者ReentrantLock将不再适用，我们迫切地需要一种分布式环境下保证线程安全的解决方案，今天我们一起来学习一下mysql分布式锁如何实现分布式线程安全。
本文介绍比较重要的一些锁，基于这些锁，对于理解MySQL的其他特性是大有帮助。部分锁例如AUT0-INC Locks有兴趣请自己发掘。
因此，悲观锁在未通过索引条件检索数据时，会锁定整张表。导致其他程序不允许“加锁的查询操作”，影响吞吐。故如果在查询居多的情况下，推荐使用乐观锁。
告知MySQL5.7.18的使用者分区表使用中存在的陷阱，避免在该版本上继续踩坑。同时通过对源码的讲解，升级MySQL5.7.18时分区表性能下降的根本原因，向MySQL源码爱好者展示分区表实现中锁的运用。
mysql锁机制分为表级锁和行级锁，本文就和大家分享一下我对mysql中行级锁中的共享锁与排他锁进行分享交流。
文章摘要 在线上环境遇到数据库死锁问题该如何分析并解决问题呢？ 虽然很多童鞋在学数据库课程时都了解数据库隔离级别、死锁和事务等概念，但在测试/线上环境遇到死锁却不一定能够及时分析并解决这类问题。本文主要以作者在测试环境中遇到的一个死锁Case说起，首先还原出现死锁的现场和条件，并结合排查业务应用工程日志、MySQL数据库状态信息等方式，同时给出MySQL锁的基本概念，再通过阅读日志深入定位并分析出现死锁的原因，最后讲下MySQL InnoDB的加锁原理以及如降低死锁发生的机率。 一、 出现死
前阵子参与了字节跳动后端青训营，其中大项目编写涉及到数据持久化一般选择使用MySQL。由于时间原因，数据库使用我选择了无脑三板斧：1. 建立了索引加速查询、2. 关闭自动提交事务、3. 在需要确保原子性的数据库操作之间手动创建和提交事务。
在计算机科学中，锁是在执行多线程时用于强行限制资源访问的同步机制，即用于在并发控制中保证对互斥要求的满足。 目录： 1、行级锁、表级锁、页级锁 2、共享锁和排它锁 3、演示 在DBMS中，可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎)、表级锁(MYISAM引擎)和页级锁(BDB引擎 )。 行级锁、表级锁、页级锁 行级锁 行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁 和 排他锁。 特点
死锁，其实是一个很有意思也很有挑战的技术问题，大概每个DBA和部分开发同学都会在工作过程中遇见 。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助
追求 MySQL 的性能时，总听说要调整自旋锁的参数: innodb_spin_wait_delay 和 innodb_sync_spin_loops，是真的么？
在mysql中锁表与表解锁，我们用到lock与unlock了，今天我来给各位朋友整理一些在使用lock tables与unlock tables过程中的一些经验分享。
数据库如下图所示，所有字段都是int(方便测试)，id为主键索引，name为普通索引（唯一索引），age没有索引
DDL 一向是业务的痛点，尤其是对大型表的 DDL 操作，具有操作时间久，对性能影响大，可能影响业务正常使用等问题。
【数据库】MySql性能监控 如何定位并优化慢查询Sql？ 具体场景具体分析，只提出大致思路。
经常有读者问如何通过 IDE 调试 MySQL 的源码分析锁相关的知识，我整理了一下之前在掘金上的几篇文章，简单介绍一下如何在 Mac 下调试和几个简单的案例。
这篇博文源于公司一个批处理的项目异常而起的。先简单描述下发生背景。一个基于spring batch开发的批处理应用，线上运行了9个多月后，某一天突然跑批任务失败了，检查日志得知，是因为一个mysql异常导致的：Lock wait timeout exceeded。msyql事务锁等待超时这个异常虽然不常见，但随便一搜就会看到大量的相关的信息。导致这个异常的原因就是mysql数据库事务锁等待超时，默认超时时间是50S。但我们的批处理业务从逻辑上讲不会出现这种事务排他锁等待的情况，不得其解。故通过以下这些实例来捋一捋mysql事务内隔离级别和锁等知识点，看看是否如我们了解的这样，同时加深下印象。
特殊说明： 以上文章，均是我实际操作，写出来的笔记资料，不会盗用别人文章！烦请各位，请勿直接盗用！转载记得标注来源！
死锁是并发系统中常见的问题，同样也会出现在数据库MySQL的并发读写请求场景中。当两个及以上的事务，双方都在等待对方释放已经持有的锁或因为加锁顺序不一致造成循环等待锁资源，就会出现“死锁”。常见的报错信息为 Deadlock found when trying to get lock...。
我今天抽时间给大家总结一个 MySQL InnoDB 存储引擎各种不同 SQL 情况下，加行锁、间隙锁、next-key lock 做一个总结。如果有错误的地方，请大家指正！
上述这个错误，接触 MySQL 的同学或多或少应该都遇到过，专业一点来说，这个报错我们称之为锁等待超时。
之前在深入了解数据库理论的时候，了解到事物的不同隔离级别可能存在的问题。为了更好的理解所以在MySQL数据库中测试复现这些问题。关于脏读和不可重复读在相应的隔离级别下都很容易的复现了。但是对于幻读，我发现在可重复读的隔离级别下没有出现，当时想到难道是MySQL对幻读做了什么处理？
TiDB 6.0 版本针对悲观事务引入了内存悲观锁的优化，带来了明显的性能提升。本文将从最初的乐观事务到悲观事务入手；介绍 6.0 版本针对悲观锁进行优化的原理，并结合压测数据验证其带来的性能提升。
形如这样的语句，在statement模式的binlog下，会对B加记录锁和间隙锁，A上会有自增锁；而在row模式下，经过测试，B表上并不会有锁。
导读：本篇记录一次服务器执行MySQL耗时的问题，耗时的问题在于一句SQL执行，耗时超过1000ms，如何解决这个问题？通过这篇文章了解下。
最近遇到一个由于唯一性索引，导致并发插入产生死锁的场景，在分析死锁产生的原因时，发现这一块还挺有意思的，涉及到MySql中不少的知识点，特此总结记录一下。
在MySQL 5.1之前的版本中，默认的搜索引擎是MyISAM，从MySQL 5.5之后的版本中，默认的搜索引擎变更为InnoDB。
redo log:存储已提交的事务,顺序写入,不需要读取操作 undo log:存储未提交事务,帮助回滚,随机读写操作
最近学习测试mybatis，单个增删改查都没问题，最后使用mvn test的时候发现了几个问题： update失败，原因是数据库死锁 select等待，原因是connection连接池被用光了，需要等待 get: 要勇于探索，坚持就是胜利。刚看到错误的时候直接懵逼，因为错误完全看不出来，属于框架内部报错，在犹豫是不是直接睡觉得了，毕竟也快12点了。最后还是给我一点点找到问题所在了。 同上，要敢于去深入你不了解的代码，敢于研究不懂的代码。 距离一个合格的码农越来越远了，因为越学越觉得漏洞百出，自己的代码到处都
虽然很多童鞋在学数据库课程时都了解数据库隔离级别、死锁和事务等概念，但在测试/线上环境遇到死锁却不一定能够及时分析并解决这类问题。本文主要以作者在测试环境中遇到的一个死锁Case说起，首先还原出现死锁的现场和条件，并结合排查业务应用工程日志、MySQL数据库状态信息等方式，同时给出MySQL锁的基本概念，再通过阅读日志深入定位并分析出现死锁的原因，最后讲下MySQL InnoDB的加锁原理以及如降低死锁发生的机率。
有一道关于「数据库锁」的面试题。我们发现其实很多 DBA （数据库管理员，Database administrator）包括工作好几年的 DBA 都答得不太好。这说明 MySQL 锁的机制其实还是比较复杂，值得深入研究。本文对3条简单的查询语句加锁情况进行分析，以期帮助各位开发者彻底搞清楚加锁细节。欢迎阅读~
在测试环境 Docker 容器中，在跨进程调用服务的时候，A 应用通过 Dubbo 调用 B 应用的 RPC 接口，发现 B 应用接口超时错误，接着通过 debug 和日志，发现具体耗时的地方在于一句简单 SQL 执行，但是耗时超过 1000ms。
原文：http://www.enmotech.com/web/detail/1/702/1.html （复制链接，打开浏览器即可查看）
我们说到事务，就得说到事务的ACID特性，为什么需要隔离性呢？因为事务要能够允许并发执行，并发执行为了同时保证数据的安全性，一致性和并发的效率，就需要设置事务的隔离级别
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
