这里注意 ‘other_values' 是一个逗号（，）分隔的字符串，如：1,2,3
这样的操作乍一看没有什么问题，但是仔细分析分析，还是有些瓶颈的，目前来看，我能分析到的瓶颈有两个，
UPDATE mytable SET myfield = ‘value’ WHERE other_field = ‘other_value’;
在MySQL中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。
MySQL 5.5 中对于二进制日志 (binlog) 有 3 种不同的格式可选：Mixed,Statement,Row，默认格式是 Statement。总结一下这三种格式日志的优缺点。 MySQL Replication 复制可以是基于一条语句 (Statement Level) ，也可以是基于一条记录 (Row Level)，可以在 MySQL 的配置参数中设定这个复制级别，不同复制级别的设置会影响到 Master 端的 bin-log 日志格式。
mysql 批量更新如果一条条去更新效率是相当的慢, 循环一条一条的更新记录,一条记录update一次，这样性能很差，也很容易造成阻塞。
对于自建 MySQL , 需要先开启 Binlog 写入功能，配置 binlog-format 为 ROW 模式，开启Mysql binlog日志步骤如下：
这句sql 的意思是，更新orderId 字段，如果id=1 则orderId 的值为3，如果id=2 则orderId 的值为4…… where部分不影响代码的执行，但是会提高sql执行的效率。确保sql语句仅执行需要修改的行数，这里只有3条数据进行更新，而where子句确保只有3行数据执行。
平时我们在设计数据库表的时候总会设计 unique 或者 给表加上 primary key 的限制条件.
之前有位小伙伴美团三面，一直被追求「幻读是否被 MySQL 可重复度隔离级别彻底解决了？」
binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
马克-to-win：既 然我们教材用mysql，我们仔细研究一下mysql缺省情况，即两个窗口都是REPEATABLE-READ(可重复读)级别的情况。两个窗口都开始事 务以后，窗口2的update,delete,insert,窗口1肯定都看不见。但双方如果都同时update,delete,insert的话，虽然 会被block住，但一旦最后两个窗口都提交，两个窗口的效果是累加的。马克-to-win：举几个例子：1）比如窗口2先要减1，虽然窗口1看不见这种变化，窗口1如果也要 减1的话，虽然当时被block住，但只要窗口2提交的话,窗口1竟然凭着select * from table能够看到累加的效果，即一共减了2。换句话说，窗口1如果不update一下，就不会看到窗口2的update的效果。2）同样道理，如果窗口 2删除了一条记录，提交以后，窗口1未提交之前，还以为这条记录存在呢。select时发现还有，但update时，不能update，也不报错。提交以 后才发觉，数据早没有了。更新半天，都是瞎忙活。马克-to-win：也好理解，因为窗口2早delete了嘛！3）如果窗口2增加一条，窗口1也想增加同样主键的这条记录 （因为看不到这条主键的记录），暂时被挡住以后，当窗口2提交，窗口1会报错，说试图增加重复键。4）窗口1想更新全部的记录为红色，同时窗口2想插入一 条蓝色的，被挡住后不能动弹键盘。窗口1必须先提交，select一下，没发觉蓝色的，等窗口2提交以后，大家都发觉，所有的都变成了红色，除了新插入的 一条是蓝色。所以还是符合提交的变化都会生效，变化的效果是累加的。5）窗口2增加一条，窗口1死活看不到这一条。即使看不见，如果愣更新这条记录的话， 会被挡在那里。马克-to-win：这时如窗口2提交，窗口1简单select，就可以看到自己update的效果。mysql的策略是，只要你叠加在别人的修改之上修改了， 在你提交之前，是可以看到这种修改的，即使你的窗口级别是REPEATABLE-READ(可重复读)。
作者：小林coding 八股文网站：xiaolincoding.com 之前有位小伙伴美团三面，一直被追问「幻读是否被 MySQL 可重复度隔离级别彻底解决了？」 之前我也提到过，MySQL InnoDB 引擎的默认隔离级别虽然是「可重复读」，但是它很大程度上避免幻读现象（并不是完全解决了），解决的方案有两种： 针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据
MySQL 5.5 中对于二进制日志 (binlog) 有 3 种不同的格式可选：Mixed,Statement,Row，默认格式是 Statement。 总结一下这三种格式日志的优缺点。 默认binlog 设置 mysql> mysql> show variables like 'binlog_%'; +-----------------------------------------+--------------+ | Variable_name |
大多数人，都会开两个窗口，分别起两个事务，然后 update 同一条记录，在发起第二次 update 请求时，block，这样就说明这行记录被锁住了：
发现，auto_increment并没有+1，而是针对原来的那一条id=4的记录进行了update，因为没有指定其他列(v,extra)的值，所以，update的时候都使用了默认值.
为了解决多个进程访问内存或磁盘中的同一份数据造成的冲突，通常有两种解决方案，一种是多版本；另一种就是锁。MySQL作为一种关系型数据库，其实也是通过这两种方式来解决数据访问冲突的。MySQL数据多版本叫MVCC，同时MySQL使用了各种类型的锁来保证数据一致性。
本文是用来系统阐述在MySQL中，不同语句在各种条件下的加锁情况，并不是解释各种锁是什么（或者说加锁的本质是什么）
或许你曾经去面试的时候被问到过关于mysql数据库的存储过程和触发器的问题，如果你还不懂可以看下这篇关于存储过程和触发器的文章，希望能帮助到有需要的朋友。
之前的一篇文章 《深入理解MySQL的MVCC原理》中总结了一下MySQL中的MVCC，它主要利用隐藏字段、版本链、ReadView来实现，可以用来更好地解决多个事务的并发【读+写】问题，但是如果在多个事务并发【写+写】的情况下，就必须要用到锁了，一般情况下，数据库的锁都是在有数据库操作的过程中自动添加的。
上一篇文章中，我们介绍了 mysql 的 crash safe 机制，也是 ACID 中原子性的实现 — redolog 的原理和配置方法。 mysql 异常情况下的事务安全 — 详解 mysql redolog
当一个事务想对这条记录进行改动时，首先会看看内存中有没有与这条记录关联的锁结构，如果没有，就会在内存中生成一个锁结构与之关联。比如，事务T1要对这条记录进行改动，就需要生成一个锁结构与之关联
当数据库中有多个操作需要修改同一数据时，不可避免的会产生数据的脏读。这时就需要数据库具有良好的并发控制能力，这一切在 MySQL 中都是由服务器和存储引擎来实现的。解决并发问题最有效的方案是引入了锁的机制，锁在功能上分为共享锁 (shared lock) 和排它锁 (exclusive lock) 即通常说的读锁和写锁； 锁的粒度上分行锁和表锁，表级锁MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)
在MySQL中，我们经常需要打开binlog来观察用户对某一个数据库的操作，binlog中记载着对用户数据库所做的所有修改类操作，例如delete，update，insert等等。binlog一般情况下分为三种格式，分别是row格式、statement格式、mixed格式，下面就这三种格式给出一些解释:
数据库隔离级别有四种，应用《高性能mysql》一书中的说明： 然后说说修改事务隔离级别的方法： 1.全局修改，修改mysql.ini配置文件，在最后加上 1 #可选参数有：READ-UNCOMMITT
INSERT INTO 表名 (字段名1, 字段名2, ...) VALUES (值1, 值2, ...);
业务系统中，使用update语句更新数据是再正常不过的场景，我们也经常通过update更新的行数，来做一些业务判断，类似下面的伪代码：(mybatis + mysql 场景)
事务就是针对数据库的一组操作。由一条或者多条SQL语句组成，同一个事务的操作具备同步的特点，如果其中的一条语句无法执行，那么所有的语句都不会执行。
背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注：MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于I
后面小节的内容和 update、delete 有关，我们先简单介绍一下这两类 SQL 语句的执行流程。
前面我们说了undo日志写入undo页面链表时，先需要把undo page header、undo segment header、undo log header等。每个事务都会有相应的undo链表，如果只存储一点数据不是很浪费吗，于是有了可重用，满足当前链表只有一个页，并且小于总空间的3/4。还介绍了回滚段，默认128个回滚段，每个段有1024个undo slot，每个slot分配给不同的事务，对应一个单独的undo页面链表。Undo日志也会记录redo日志，但临时表的undo日志写入不会记录redo日志，他的记录过程是先修改了数据，则会在系统表空间申请一个rollback segment header页面地址，循环获取，从第0号，第33~127号。分配了回滚段后，在段里查看cache是否存在undo slot，不存在就去rollback_segment_header找到一个undo slot分配该事务，如果没找到，则需要去undo log segment申请一个first undo page
本文针对上一篇《MySQL优化案例分享》文章中提到的线上业务产生的一个死锁问题进行展开讨论，主要针对两个update操作导致的死锁的场景，借此机会正好总结下MySQL锁及分析下产生死锁的原因和解决方案；
面试官反问的大概意思是，MySQL 记录锁+间隙锁可以防止删除操作而导致的幻读吗？
其实啊，“XXX语句该加什么锁”本身就是个伪命题，一条语句需要加的锁受到很多条件制约，比方说：
通过上文《MySQL是如何保证数据不丢失的？》可以了解DML的操作流程以及数据的持久化机制。对于一个数据库而言，除了数据的持久性、不丢失之外，一致性也是非常重要的，不然这个数据是没有任何意义的。在使用MySQL时，数据不一致的情况也可能出现，所以，本文就来看看MySQL是如何保证数据一致的。
问题归纳起来就是：在MySQL里面update一条记录，语法都正确的，但记录并没有被更新…
生活中，最常见的案例之一，十字路口没有红绿灯，到了十字路口相互不让，最后，整个马路瘫痪，在我们技术层面称之为死锁。
事务(Transaction) 是访问和更新数据库的基本执行单元，一个事务中可能会包含多个 SQL 语句，事务中的这些 SQL 语句要么都执行，要么都不执行，而 MySQL 它是一个关系型数据库，它自然也是支持事务的。事务同时也是区分关系型数据库和非关系型数据库的一个重要的方面。
RU/RC 情况下加锁情况基本一致, 在加锁情况下脏读和不可重复读在任何一个隔离级别下都不会发生（因为读-写操作需要排队进行)
默认情况下，InnoDB工作在可重复读隔离级别下，并且会以Next-Key Lock的方式对数据行进行加锁，这样可以有效防止幻读的发生。Next-Key Lock是行锁和间隙锁的组合，当InnoDB扫描索引记录的时候，会首先对索引记录加上行锁（Record Lock），再对索引记录两边的间隙加上间隙锁（Gap Lock）。加上间隙锁之后，其他事务就不能在这个间隙修改或者插入记录。
在写日志的时候，单个日志如果过大，对于读写和同步都会产生影响，所以在日志变大的时候，需要对日志进行一个分组。
最近总结了一波死锁问题，和大家分享一下，我这也是从网上各种浏览博客得来，希望原作者见谅，参考博客文末下方。
问题描述 在做项目的过程中，由于写SQL太过随意，一不小心就抛了一个死锁异常，如下：
1、效率太差，每次执行都要执行2个sql 2、高并发的情况下数据会出问题，不能保证原子性
Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
blog.csdn.net/tr1912/article/details/81668423
所谓死锁：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
