MySQL实战45讲
林晓斌
网名丁奇,前阿里资深技术专家
立即订阅
43177 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 这一次,让我们一起来搞懂MySQL
免费
基础篇 (8讲)
01 | 基础架构:一条SQL查询语句是如何执行的?
02 | 日志系统:一条SQL更新语句是如何执行的?
03 | 事务隔离:为什么你改了我还看不见?
04 | 深入浅出索引(上)
05 | 深入浅出索引(下)
06 | 全局锁和表锁 :给表加个字段怎么有这么多阻碍?
07 | 行锁功过:怎么减少行锁对性能的影响?
08 | 事务到底是隔离的还是不隔离的?
实践篇 (37讲)
09 | 普通索引和唯一索引,应该怎么选择?
10 | MySQL为什么有时候会选错索引?
11 | 怎么给字符串字段加索引?
12 | 为什么我的MySQL会“抖”一下?
13 | 为什么表数据删掉一半,表文件大小不变?
14 | count(*)这么慢,我该怎么办?
15 | 答疑文章(一):日志和索引相关问题
16 | “order by”是怎么工作的?
17 | 如何正确地显示随机消息?
18 | 为什么这些SQL语句逻辑相同,性能却差异巨大?
19 | 为什么我只查一行的语句,也执行这么慢?
20 | 幻读是什么,幻读有什么问题?
21 | 为什么我只改一行的语句,锁这么多?
22 | MySQL有哪些“饮鸩止渴”提高性能的方法?
23 | MySQL是怎么保证数据不丢的?
24 | MySQL是怎么保证主备一致的?
25 | MySQL是怎么保证高可用的?
26 | 备库为什么会延迟好几个小时?
27 | 主库出问题了,从库怎么办?
28 | 读写分离有哪些坑?
29 | 如何判断一个数据库是不是出问题了?
30 | 答疑文章(二):用动态的观点看加锁
31 | 误删数据后除了跑路,还能怎么办?
32 | 为什么还有kill不掉的语句?
33 | 我查这么多数据,会不会把数据库内存打爆?
34 | 到底可不可以使用join?
35 | join语句怎么优化?
36 | 为什么临时表可以重名?
37 | 什么时候会使用内部临时表?
38 | 都说InnoDB好,那还要不要使用Memory引擎?
39 | 自增主键为什么不是连续的?
40 | insert语句的锁为什么这么多?
41 | 怎么最快地复制一张表?
42 | grant之后要跟着flush privileges吗?
43 | 要不要使用分区表?
44 | 答疑文章(三):说一说这些好问题
45 | 自增id用完怎么办?
特别放送 (1讲)
直播回顾 | 林晓斌:我的 MySQL 心路历程
结束语 (1讲)
结束语 | 点线网面,一起构建MySQL知识网络
MySQL实战45讲
登录|注册

15 | 答疑文章(一):日志和索引相关问题

林晓斌 2018-12-17
在今天这篇答疑文章更新前,MySQL 实战这个专栏已经更新了 14 篇。在这些文章中,大家在评论区留下了很多高质量的留言。现在,每篇文章的评论区都有热心的同学帮忙总结文章知识点,也有不少同学提出了很多高质量的问题,更有一些同学帮忙解答其他同学提出的问题。
在浏览这些留言并回复的过程中,我倍受鼓舞,也尽我所知地帮助你解决问题、和你讨论。可以说,你们的留言活跃了整个专栏的氛围、提升了整个专栏的质量,谢谢你们。
评论区的大多数留言我都直接回复了,对于需要展开说明的问题,我都拿出小本子记了下来。这些被记下来的问题,就是我们今天这篇答疑文章的素材了。
到目前为止,我已经收集了 47 个问题,很难通过今天这一篇文章全部展开。所以,我就先从中找了几个联系非常紧密的问题,串了起来,希望可以帮你解决关于日志和索引的一些疑惑。而其他问题,我们就留着后面慢慢展开吧。

日志相关问题

我在第 2 篇文章《日志系统:一条 SQL 更新语句是如何执行的?》中,和你讲到 binlog(归档日志)和 redo log(重做日志)配合崩溃恢复的时候,用的是反证法,说明了如果没有两阶段提交,会导致 MySQL 出现主备数据不一致等问题。
在这篇文章下面,很多同学在问,在两阶段提交的不同瞬间,MySQL 如果发生异常重启,是怎么保证数据完整性的?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《MySQL实战45讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(141)

  • 某、人 置顶
    孔乙己来到酒馆大喊一声老板来二两酒赊着,酒馆生意太好,老板把孔乙己的欠账记录记到小黑板上并记录了孔乙己点的菜单。孔乙己跟别人吹了会牛,忘了叫的几两酒了。又给老板说,老板把酒改成二两。老板也不确定孔乙己叫没叫酒,就去查菜单,发现孔乙己确实点了酒,但是本来就二两,也就难得麻烦了,又要修改小黑板,又要改菜单。直接就给孔乙己说已经改好了。😄

    作者回复: 老板看完板,正要告知孔乙己今日总账是赊账二两酒,
    小二连忙过来拦住,“老板,刚刚孔乙己刚又赊账了一碟茴香豆。”
    老板大惊,“差点亏了我一碟豆子!我怎不知?”
    小二道,“老板你方才看板的之时没拿记账笔,我看记账笔没人使用,按店规自然可用。老板你自己没看”

    老板惊呼,“亏的你小心”。

    暗地想店规确有不妥。

    于是把店规“变账须用记账笔。” 改为
    “改帐均须动笔。纵为不变之帐,仍需覆写之”

    😄

    2018-12-17
    120
  • 萤火虫 置顶
    林老师的每次更新我都会跟着看 跟着学 已经坚持15节课了 受益良多 只是心里有时会反问自己 底层原理有那么重要吗? 会用不就行了吗? 自己不知道该怎么推翻这些想法 加上自己有个不好的习惯 就是容易放弃 希望自己能够坚持到最后。

    作者回复: 加油。

    说下我自己的理解。

    我在带新人的时候,要求大家在写SQL语句的时候,心里是有数的,知道每个语句执行的结果,以及这些代码会消耗什么资源、如果慢了会慢在哪里、每个语句执行会占用哪些锁等等。

    有的新人会问“为什么需要这么麻烦,我执行一下,看看结果对不对,对了就行,不对就改,是不是也可以?”

    我说不可以。因为如果这样,我们就会受到很多局限,即使我们定位自己是业务开发人员。

    这里我说一个限制:

    这会限制基于数据库的业务架构能力。一个语句可以试,一个五个语句的事务分析就要试很多次,一个复杂业务系统的数据库设计,是试不出来的。

    原理可以帮我们剪枝,排除掉那些理论上明显错误的方案,这样才有精力真的去试那些有限的、可能正确的方案。


    我们不需要100%精通MySQL(我自己离这个目标也相去甚远),但是只要多知道一些原理,就能多剪一些枝,架构设计就能少一些错误选项的干扰,设计出来的项目架构正确的可能性更高。

    我自己特别喜欢这个剪枝的过程和感觉,他表示我用以前学习的时间,来节省了现在工作的时间。


    当然,“原理”是一个很大的概念,有的原理更接近实战,有的远一些。这个专栏我挑的是跟平时使用相关的原理,以便大家可以有机会边学边用。

    一起加油吧🤝

    2018-12-17
    3
    101
  • Gavin 置顶
    课后问题:
    在命令行先执行以下命令(注意不要提交事务):
    BEGIN;
    UPDATE t SET a=2 WHERE id=1;

    新建一个命令行终端,执行以下命令:
    UPDATE t SET a=2 WHERE id=1;

    从新建的命令行终端的执行结果看,这条更新语句被阻塞了,如果时间足够的话(InnoDB行锁默认等待时间是50秒),还会报锁等待超时的错误。
    综上,MySQL应该是采用第3种方式处理题述场景。

    对于MySQL为什么采用这种方式,我们可以利用《08 | 事务到底是隔离的还是不隔离的?》图5的更新逻辑图来解释:假设事务C更新后a的值就是2,而事务B执行再执行UPDATE t SET a=2 WHERE id=1;时不按第3种方式处理,即不加锁不更新,那么在事务B中接下来查询a的值将还是1,因为对事务B来说,trx_id为102版本的数据是不可见的,这就违反了“当前读的规则”。

    以上是我的理解与分析,不是很确定准确与否。

    作者回复: 漂亮

    2018-12-17
    2
    62
  • null 置顶
    看到自己的问题上榜,这是对自己的最大鼓励。

    学习专栏之前,自己只是一个 CRUD boy,平时同事间讨论 MySQL 的问题,自己完全搭不上话,因为对 MySQL 底层原理完全不懂。对 MySQL 的认知就仅限一点:索引能提高查询效率。但是为什么能提高?不知道!!

    现在回想,以前犯过很多错误:
    1. 主键使用 UUID,非自增主键。
    2. 滥用索引,其实可以通过“最左前缀原则”来精减索引。
    3. 不管 SQL 语句是否合理,只要能返回结果集就是好 SQL。
    4. 建表时字段类型拿捏不准。

    现在都会反复学习专栏的每一篇文章,每次学习都有不一样的收获。
    第一次可能是:喔,原来有这么个知识点,但对它的实现原理一知半解。
    第二次却是:对它的实现原理有了更深的认识,加强对知识的理解,基本会形成一个比较清晰的逻辑。
    第三次是,MySQL 的这种实现原理,是为了解决什么问题等等。

    现在感觉有点“走火入魔”了,以前执行查询语句,关注的多久能返回结果集。
    现在关注的却是:连接器、分析器、优化器、执行器和 InnoDB 引擎。
    连接成功后,获取我的权限,查询缓存,命中缓存直接返回,否则进行后续的操作。(记得老师留言区回复过:连接器取权限,执行器用权限。而编写留言到这产生了一个疑问:查询缓存前,应该会校验权限,所以连接器也会用权限?)
    分析器阶段进行词法分析,解析关键字,字段名,表名等。语法分析判断语法是否正确。(记得第一篇《基础架构》留言提到语义分析,今晚要找资料学习下)。
    优化器阶段生成执行计划,选择索引(这时会怀疑 MySQL 选择的索引是否最优),能否使用索引下推和覆盖索引减少回表查询,提高性能。
    执行器阶段调用引擎接口查询数据,Server 层要啥,引擎给啥,InnoDB 只给必要的值。
    查询结束后,返回结果集,并将结果集放入查询缓存。

    更新语句的关注点是隔离性,视图,MVCC,回滚日志,redo log,binlog,两阶段提交等。
    写业务代码时,会考虑事务内的 SQL 语句,能否调整 SQL 语句的顺序,减少更新表时行锁对性能的影响。
    在建表的时,会反复推敲这个索引是否合理。使用普通索引还是唯一索引更为合适。能否通过“最左前缀原则”来减少创建索引的个数。如果索引字段的类型是字符串并长度太长,如何优化使用前缀索引,减少空间占用,提高查询性能。

    学习专栏后,基本上涉及到 MySQL 的内容,这些知识点都会浮现在脑海中。昨天还差点应用这些知识,帮同事优化他的 SQL 语句。昨天跟往常一样,当写代码写累了,就跑到同事那溜达溜达。
    他正在线上的备库测试查询百万数据要多久,另一位同事建议他使用 force index 强制索引,这次执行 5 秒,再执行零点几秒。
    他惊乎,为啥这次这么快。我说,这次查了缓存。我还想帮他看看 SQL 语句,是否 MySQL 选择错了索引,导致使用 force index 显式指定索引。说不定使用 order by field 就解决了呢,哈哈哈哈。后面有事,没有继续跟进他这问题了。

    非常感恩,跟着老师学习,让我体会到了学习是一件自然而又充满魅力的事情,也让我从一个基础不牢固的小白,一步步地充实了自己的知识库,另外老师非常尽责,经常半夜回复答疑,希望老师保重身体。谢谢!!

    作者回复: “我说,这次查了缓存”

    哈哈,这个场景好棒,这个画面感,有一种扫地僧的感觉👍🏿

    一起加油

    2018-12-18
    1
    36
  • 力挽狂澜爆炸输出的臭臭宁 置顶
    针对不能只用binlog完成数据恢复我的理解:
    按照文中这个话题下的示例,因为MySQL写数据是写在内存里的,不保证落盘,所以commit1的数据也可能丢失;但是恢复只恢复binlog失败的也就是commit2的数据,所以数据会丢失。
    这样理解对吗?

    作者回复: 是的,binlog一来时机控制不好(就是你说的这个),二来内容的能力不足(没有页面信息)
    👍🏿

    2018-12-20
    1
    11
  • Eric
    老师,您实在是太良心了。整理这些问题应该很费时间吧。看完答疑之后感觉又加深了一遍印象。像很多知识点都需要反复理解才能真正掌握。答疑来的很及时,感谢!
    2018-12-17
    26
  • 陈新仁
    【操作符“|”是逻辑或,连同最后一句insert语句里...】
    老师,“|” 这应该叫位运算符的按位或操作符,逻辑或是“||”吧?
    这里的幂等性原理就是:A < B: relation_ship = 2 | 1; A > B:relation_ship = 1 | 2;重复插入 3 | 1 或者 3 | 2 。位运算: 2 | 1 == 1 | 2 == 3 | 1 == 3 | 2 == 3。感觉这里想法很巧妙。

    作者回复: 你说得对,是按位或,看得很细致👍🏿

    我发个堪误

    2018-12-17
    2
    23
  • 于海
    在极客时间也学了不少课程,林老师是这其中最认真负责的,好的课程是用“心”写出来的

    作者回复: 谢谢🙏
    希望大家都有收获

    2018-12-17
    22
  • WL
    关于刷脏页有两个问题请教老师:
    1. 当redo log空间不足时, 按照redo log的顺序把脏页更新到磁盘, 那么假如一个脏页在第1条redo log中已经被持久化到磁盘, 后面第1000条redo log又有这个关于这个脏页的信息, 那么innoDB是直接丢弃掉这条redo log的记录吗? 还有这个时候, 是要把redo log上的全部内容更新到磁盘吗, 还是更新一部分?

    2. 当内存不足开始刷脏页的时候, 以内存为刷脏页发起点, 这时是把最久不使用的数据页从内存中淘汰掉, 那么这个时候, 对应的额redo log是不是也会清除? 而对于该脏页的操作可能在redo log中并不是连续的记录, redo log有只能顺序读写, 那么redo log是怎么清除掉关于这个脏页的所有记录的?

    作者回复: 1. 刷脏页是只把内存上最新版本的数据页写到磁盘上。 第一个碰到的redolog会把这个脏页刷下去,注意redolog并没有修改内存数据页的数据(这个不是崩溃恢复过程哦)
    后面再碰到这个页面的redolog,这个页面是干净页了,不用刷直接跳过

    2. 第二个问题的两个问号是一个答案:不用清除。 下次redo log来刷的时候看到是干净页就直接过了。

    好问题。

    2018-12-22
    1
    7
  • melon
    思考题:应该是第三种,因为两个事务并行执行该update,有一个会卡住,说明有加锁,而且update语句执行后,查看ibd文件和redo log文件的修改时间都更新了。通过show engine innodb status 进一步验证,查看LSN确实增加了,而且Number of rows updated 也加+1了。
    2018-12-17
    7
  • greatcl
    看评论里有人说足够有钱把redo log设置无限大,老师已经回复说不能设置无限大。
    在MySQL的一个文档里https://dev.mysql.com/doc/refman/5.6/en/innodb-init-startup-configuration.html#innodb-startup-log-file-configuration看到全部redo log文件的大小是不能超过512GB的。
    文档里建议redo log全部文件总大小的设置要能满足业务系统一个小时写操作的量,当然如果磁盘足够这个是能尽量大点就大点的。
    二刷能学到更多的知识^_^
    2019-04-25
    3
  • 小白
    老师,请教个问题,为什么要比较AB的大小,这快逻辑没有看懂

    如果是 a喜欢b 那就insert into `like`(user_id, liker_id, relation_ship) values(A, B, 1)
    如果是 b喜欢a 那就insert into `like`(user_id, liker_id, relation_ship) values(B, A, 1)
    不是应该这个逻辑么?我理解错了哪里老师
    2019-04-17
    2
    3
  • 观弈道人
    丁老师,不好意思,刚才提的A > B, A < B问题,我要再重复一下。A > B: 应该是表示当前业务操作为A用户关注B用户, sql为: insert into like('a_user_id', 'b_user_id', 1), 如果反向关联则为insert into like('b_user_id', 'a_user_id', 2), 互相关联则relation_ship update 为3, 您的意思是通过relation_ship表示user_id,liker_id哪个为被关注方,哪个是关注方,所以,我还是理解 A > B ,不应该理解成 A 大于 B,而是A 关注 B,我认为A 大于 B的比较是没有意义的,比较疑惑我这样理解偏差在哪里?😖

    作者回复: 不是A关注B,就是A大于B,说的是用户id哦

    2019-01-02
    3
  • mahonebags
    我给表新加了一个update_time on update current_timestamp字段,发现会加锁,但是提交后update_time不会变化,而且也没有binlog生成,所以是加锁了但是实际没更新?
    2018-12-18
    3
  • 郭江伟
    创建测试数据:
    mysql> create table t(id int primary key auto_increment,a int );
    mysql> insert into t values(1,2);
    mysql> begin;
    Query OK, 0 rows affected (0.00 sec)
    mysql> update t set a=2 where id=1;
    Query OK, 0 rows affected (0.00 sec)
    查看系统锁情况:
    show engine innodb status
    ---TRANSACTION 958998, ACTIVE 51 sec
    2 lock struct(s), heap size 1136, 1 row lock(s)
    MySQL thread id 2, OS thread handle 139663691581184, query id 22 localhost root
    mysql> show processlist;
    +----+------+-----------+--------------------+---------+------+----------+------------------+
    | Id | User | Host | db | Command | Time | State | Info |
    +----+------+-----------+--------------------+---------+------+----------+------------------+
    | 2 | root | localhost | sysbench | Sleep | 352 | | NULL |
    | 3 | root | localhost | NULL | Sleep | 301 | | NULL |
    +----+------+-----------+--------------------+---------+------+----------+------------------+
    其中Thread id=2 为update会话,说明系统有锁
    另一会话执行 update t set a=2 where id=1;
    ERROR 1205 (HY000): Unknown error 1205 MySQL error code 1205 (ER_LOCK_WAIT_TIMEOUT): Lock wait timeout exceeded; try restarting transaction
    提交第一个会话查看生成的binlog
    ### INSERT INTO `sysbench`.`t`
    ### SET
    ### @1=1 /* INT meta=0 nullable=0 is_null=0 */
    ### @2=2 /* INT meta=0 nullable=1 is_null=0 */
    # at 858
    #181217 14:28:21 server id 9012 end_log_pos 889 CRC32 0xf96f7fcb Xid = 20
    COMMIT/*!*/;
    # at 889
    #181217 14:42:14 server id 9012 end_log_pos 930 CRC32 0x3de034ba Rotate to bin.000089 pos: 4
    SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
    DELIMITER ;
    # End of log file
    /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
    /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
    发现没有update的binlog产生,也就是说该语句在server层没有实际执行
    用hexdump对比update前后的数据行,发现事务id和回滚id也没变,说明innodb没有实际更新行。
    鉴于该语句产生了行锁,有事务信息,但是没有实际修改,可判断innodb在更新前后值一样时不会实际更新数据

    作者回复: Hexdump前有没有关闭MySQL?

    2018-12-17
    3
  • 某、人
    老师提几个问题:
    1.事务在执行过程中,binlog是否像redo log一样记录到binlog_cache里?
    2.为什么把redo log buffer设置成全局参数,binlog cache设置为事务级别参数?
    3.为什么一般是binlog落盘比redo log更耗时?
    4.如果sync为1,dump线程是等到binlog 成功flush,再从binlog cache中把binlog event发送给从库?如果非1,是在最后xid写入就从binlog cache中把binlog event发送给从库?

    作者回复: 1. 嗯,它有单独的内存,redo log buffer

    2. Binlog cache size也是global 的呀,我还去确认了5.5~5.7,你用的是哪个版本?

    3. 这个数据是怎么得到的😄

    4. 写完磁盘就发,然后再回来flush。
         不是,放在binlog cache表示“这事务还没做完”,不发的

    2018-12-17
    3
  • 不惑ing
    问:2.追问5:binlog1丢失的原因是因为数据还在内存没刷到磁盘?如果设置innodb_flush_log_at_trx_commit=1 每次commit都刷到磁盘是不是就不会丢失了?这个两个理解有问题么?

    Re:2. 追问5的回答的意思是,如果没有两阶段,redo log先提交完成再写binlog的话,就会导致binlog写入过程如果发生错误,无法回滚

    老师您好,不好意思我没表达清楚,非常抱歉,重新问一遍,您文中的意思是【只用binlog做崩溃恢复,在图二crash位置,无法持崩溃恢复,图中binlog1已经commit了也会丢失】,
    这段我没理解,为啥binlog1已经commit了还会丢失数据,所以引发了后面的思考
    【binlog1丢失的原因是因为数据还在内存没刷到磁盘?如果设置innodb_flush_log_at_trx_commit=1 每次commit都刷到磁盘是不是就不会丢失了?】
    2019-02-24
    2
    2
  • linqw
    由于工作的原因最近一段时间,没有看,为此这周末赶紧恶补了一下,在redo log和binlog的答疑中,写下自己的理解,老师帮忙看下哦
    1、redo log和binlog采用两阶段提交,目的是为了双方能多一个选择,在mysql宕机时,如果redo log处于commit,事务直接提交,如果redo log处于prepare,binlog完整事务也提交,只有在binlog不完整时,事务会回滚,以前更新数据页会丢失。
    2、redo log如何和binlog联系在一起,XID,在服务重启启动时,会扫描redo log中xid字段到binlog中,找相对应的事务,判断binlog的状态是否需要提交
    3、能否在redo log写完整在写binlog么?不行,因为redo log写完,表示事务已经提交,如果在binlog写入的过程中出现异常,会导致redo log和binlog的数据不一致的问题,如果使用binlog恢复库,会导致主库和从库的数据不一致,因为redo log已提交,binlog没有写入成功,为此需要采用两阶段提交。
    4、redo log和redo buffer的联系?
    即在数据更新时,会先写redo buffer,因为这样可以在写redo log时,先把数据保存起来,在commit时在把数据写入redo log中,因为这样更新的时候会更快,直接更新内存,在事务处于cmmit时,才将内存中的数据写到redo log中。
    5、数据页回复是使用buffer pool还是redo log?
    redo log只有在数据页出现异常的时候,将其拿来恢复上次更新的数据页,但是redo log没有记录完整的数据页数据,为此在正常的情况下,都没有使用redo log,是使用buffer pool将起内部以前的数据刷新到磁盘中,其实想说,脏(这个字不会打,尴尬的一批)数据?
    6、redo log一般设置多大?这个老师上面说的很清楚,如果磁盘的容量大,就多搞点,如果小的话可以向公司申请买好设备,要是不同意的话,就得问你们老板了,项目已si,开玩笑,哈哈哈。
    7、只用redo log?其实你要是公司机器够大,可以设置成无限大,额,可以假装binlog,额,开玩笑的,因为redo log只有循环写,没法当做binlog,只要有钱就不好说了。
    8、只用binlog?不行,为啥不行,百度啊,不行谷歌,好啦,开玩笑,发一下烧,因为如果在一个事务里面,同时写binlog,你看看会有什么问题,一个成功执行,一个执行失败,那会导致一个binlog可以回复数据页,一个不行,为此,导致数据页不一致,好了,今天不知道为啥那么兴奋,额,可能是,你猜吧,好了,写完我也忘了,一起拍砖

    作者回复:

    1. 两阶段提交主要还是因为有了两份日志😆,两份日志的历史原因多些;
    2. 对的,XID
    3. 是,要考虑binlog和数据的一致性;
    4. 对的
    5. 是脏页哈
    6. 😅
    7. 不能设置无限大
    8. 是不是暗恋的妹子向你表白了😝

    2019-01-27
    2
  • 郭刚
    结论是方式3:
    autocommit设置的是0

    实验过程:
    session1:
    mysql> update t set a=2 where id=1;
    Query OK, 0 rows affected (0.00 sec)
    Rows matched: 1 Changed: 0 Warnings: 0
    session2:
    mysql> update t set a=2 where id=1;
    ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
    2018-12-17
    2
  • miche
    老师,经过前面的精彩内容,redo log和binlog已经理解的差不多了,能不能说一下undo log是怎么工作的吗?一个update语句从开始到结束,这undo和redo是先开始写哪个日志的?
    2018-12-17
    2
收起评论
99+
返回
顶部