MySQL
文章平均质量分 92
阿昌喜欢吃黄桃
这个作者很懒,什么都没留下…
展开
-
Day970.数据库表解耦 -遗留系统现代化实战
一张表格,对比了拆分查询 SQL 的三种方案,以及上面没有提到的一些优势和不足。结合自己的实际需求,对照表格选择更合理的方案。解耦数据库表的方法都是基于查询的 SQL,对于 INSERT、UPDATE 和 DELETE 的 SQL,也可以用 API 调用来取代。原创 2023-05-16 23:24:24 · 1333 阅读 · 0 评论 -
Day963.如何拆分数据 -遗留系统现代化实战
Hi,我是阿昌,今天学习记录的是关于如何拆分数据的内容。,这个场景在建设新老城区,甚至与其他城市(外部系统)交互时都非常重要。作为开发人员,理想中的业务数据存储方式是什么样呢?当然是负责一个业务的数据都在一张或几张名称相关的表中,这样通过名称就可以一目了然,查找起来很方便。不过很遗憾,现实有时候总是事与愿违,遗留系统中负责处理一个业务的数据,有的放在这张表,有的放在那张表,总是不在一起,名称甚至都没关系;而一张表中也有可能存放几种业务的数据。原创 2023-05-07 16:35:07 · 745 阅读 · 0 评论 -
Day909.MySQL 不同的自增 id 达到上限以后的行为 -MySQL实战
说到自增 id,第一个想到的应该就是表结构定义里的自增字段,在自增主键为什么不是连续的?中和介绍过的自增主键 id。表定义的自增值达到上限后的逻辑是:再申请下一个 id 时,得到的值保持不变。//成功插入一行 4294967295 show create table t;原创 2023-03-06 21:28:25 · 1363 阅读 · 1 评论 -
Day908.join&snlj&dist和group问题和备库自增主键问题 -MySQL实战
Hi,我是阿昌,今天学习记录的是关于的内容。原创 2023-03-05 20:47:40 · 1391 阅读 · 0 评论 -
Day907.分区表 -MySQL实战
需要注意的是,我是以范围分区(range)为例和你介绍的。实际上,MySQL 还支持 hash 分区、list 分区等分区方法。可以在需要用到的时候,再翻翻手册。实际使用时,分区表跟用户分表比起来,有两个绕不开的问题:一个是第一次访问的时候需要访问所有分区,另一个是共用 MDL 锁。因此,如果要使用分区表,就不要创建太多的分区。见过一个用户做了按天分区策略,然后预先创建了 10 年的分区。这种情况下,访问分区表的性能自然是不好的。分区并不是越细越好。原创 2023-03-04 23:04:10 · 852 阅读 · 0 评论 -
Day906.grant语句 -MySQL实战
介绍MySQL 用户权限在数据表和内存中的存在形式,以及 grant 和 revoke 命令的执行逻辑。grant 语句会同时修改数据表和内存,判断权限的时候使用的是内存数据。因此,规范地使用 grant 和 revoke 语句,是不需要随后加上 flush privileges 语句的。flush privileges 语句本身会用数据表的数据重建一份内存权限数据,所以在权限数据可能存在不一致的情况下再使用。而这种不一致往往是由于直接用 DML 语句操作系统权限表导致的,所以尽量不要使用这类语句。原创 2023-03-03 19:48:53 · 898 阅读 · 0 评论 -
Day905.复制表 -MySQL实战
三种将一个表的数据导入到另外一个表中的方法。对比一下这三种方法的优缺点。用物理拷贝的方式速度最快,尤其对于大表拷贝来说是最快的方法。如果出现误删表的情况,用备份恢复出误删之前的临时库,然后再把临时库中的表拷贝到生产库上,是恢复数据最快的方法。但是,这种方法的使用也有一定的局限性:必须是全表拷贝,不能只拷贝部分数据;需要到服务器上拷贝数据,在用户无法登录数据库主机的场景下无法使用;由于是通过拷贝物理文件实现的,源表和目标表都是使用 InnoDB 引擎时才能使用。用 mysqldump。原创 2023-03-02 21:53:28 · 355 阅读 · 0 评论 -
Day904.特殊情况下的 insert 语句 -MySQL实战
insert … select 是很常见的在两个表之间拷贝数据的方法。在可重复读隔离级别下,这个语句会给 select 的表里扫描到的记录和间隙加读锁。如果 insert 和 select 的对象是同一个表,则有可能会造成循环写入。这种情况下,需要引入用户临时表来做优化。insert 语句如果出现唯一键冲突,会在冲突的唯一值上加共享的 next-key lock(S 锁)。因此,碰到由于唯一键约束导致报错后,要尽快提交或回滚事务,避免加锁时间过长。原创 2023-03-01 22:15:46 · 813 阅读 · 1 评论 -
Day903.自增主键不能保证连续递增 -MySQL实战
在 MyISAM 引擎里面,自增值是被写在数据文件上的。而在 InnoDB 中,自增值是被记录在内存的。MySQL 直到 8.0 版本,才给 InnoDB 表的自增值加上了持久化的能力,确保重启前后一个表的自增值不变。自增值改变的时机,分析了为什么 MySQL 在事务回滚的时候不能回收自增 id。MySQL 5.1.22 版本开始引入的参数 innodb_autoinc_lock_mode,控制了自增值申请时的锁范围。原创 2023-02-28 22:17:58 · 558 阅读 · 0 评论 -
Day902.Memory存储引擎 -MySQL实战
由于重启会丢数据,如果一个备库重启,会导致主备同步线程停止;如果主库跟这个备库是双 M 架构,还可能导致主库的内存表数据被删掉。因此,在生产上,不建议你使用普通内存表。如果是 DBA,可以在建表的审核系统中增加这类规则,要求业务改用 InnoDB 表。InnoDB 表性能还不错,而且数据安全也有保障。而内存表由于不支持行锁,更新语句会阻塞查询,性能也未必就如想象中那么好。基于内存表的特性,还分析了它的一个适用场景,就是内存临时表。原创 2023-02-27 21:52:38 · 509 阅读 · 0 评论 -
Day900.MySql用户临时表 -MySQL实战
在实际应用中,临时表一般用于处理比较复杂的计算逻辑。由于临时表是每个线程自己可见的,所以不需要考虑多个线程执行同一个处理逻辑时,临时表的重名问题。在线程退出的时候,临时表也能自动删除,省去了收尾和异常处理的工作。在 binlog_format='row’的时候,临时表的操作不记录到 binlog 中,也省去了不少麻烦,这也可以成为选择 binlog_format 时的一个考虑因素。需要注意的是,上面说到的这种临时表,是用户自己创建的 ,也可以称为用户临时表。与它相对应的,就是内部临时表。原创 2023-02-25 23:08:15 · 1387 阅读 · 0 评论 -
Day899.Join语句优化 -MySQL实战
Index Nested-Loop Join(NLJ)和 Block Nested-Loop Join(BNL)的优化方法。BKA优化是 MySQL 已经内置支持的,建议默认使用;BNL 算法效率低,建议你都尽量转成 BKA 算法。优化的方向就是给被驱动表的关联字段加上索引;基于临时表的改进方案,对于能够提前过滤出小数据的 join 语句来说,效果还是很好的;MySQL 目前的版本还不支持 hash join,但可以配合应用端自己模拟出来,理论上效果要好于临时表的方案。原创 2023-02-24 23:12:19 · 750 阅读 · 0 评论 -
Day898.Join语句执行流程 -MySQL实战
如果可以使用被驱动表的索引,join 语句还是有其优势的;不能使用被驱动表的索引,只能使用 Block Nested-Loop Join 算法,这样的语句就尽量不要使用;在使用 join 的时候,应该让小表做驱动表。使用 Block Nested-Loop Join 算法,可能会因为 join_buffer 不够大,需要对被驱动表做多次全表扫描。如果被驱动表是一个大表,并且是一个冷数据表,除了查询过程中可能会导致 IO 压力大以外,觉得对这个 MySQL 服务还有什么更严重的影响吗?原创 2023-02-23 22:11:19 · 884 阅读 · 1 评论 -
Day897.MySQL查询结果发送给客户端的过程 -MySQL实战
用“大查询会不会把内存用光”这个问题,和介绍了 MySQL 的查询结果,发送给客户端的过程。由于 MySQL 采用的是边算边发的逻辑,因此对于数据量很大的查询结果来说,不会在 server 端保存完整的结果集。所以,如果客户端读结果不及时,会堵住 MySQL 的查询过程,但是不会把内存打爆。而对于 InnoDB 引擎内部,由于有淘汰策略,大查询也不会导致内存暴涨。并且,由于 InnoDB 对 LRU 算法做了改进,冷数据的全表扫描,对 Buffer Pool 的影响也能做到可控。原创 2023-02-22 22:21:54 · 453 阅读 · 0 评论 -
Day896.MySql的kill命令 -MySQL实战
这些“kill 不掉”的情况,其实是因为发送 kill 命令的客户端,并没有强行停止目标线程的执行,而只是设置了个状态,并唤醒对应的线程。而被 kill 的线程,需要执行到判断状态的“埋点”,才会开始进入终止逻辑阶段。并且,终止逻辑本身也是需要耗费时间的。所以,如果发现一个线程处于 Killed 状态,可以做的事情就是,通过影响系统环境,让这个 Killed 状态尽快结束。比如,如果是第一个例子里 InnoDB 并发度的问题,就可以临时调大 innodb_thread_concurrency 的值,或者。原创 2023-02-21 21:28:15 · 4601 阅读 · 1 评论 -
Day895.MySql误删数据还原方案 -MySQL实战
Hi,我是阿昌,今天学习记录的是关于的内容。传统的高可用架构是不能预防误删数据的,因为主库的一个drop table命令,会通过binlog传给所有从库和级联从库,进而导致整个集群的实例都会执行这个命令。虽然之前遇到的大多数的数据被删,都是运维同学或者 DBA 背锅的。但实际上,只要有数据操作权限的同学,都有可能踩到误删数据这条线。原创 2023-02-20 22:18:16 · 647 阅读 · 0 评论 -
Day894.加锁规则的一些问题 -MySQL实战
Hi,我是,今天学习记录的是关于的内容。加锁规则,这个规则中,包含了两个“原则”、两个“优化”和一个“bug”:接下来,是基于下面这个表 t:一、不等号条件里的等值查询来看下这个例子,分析一下这条查询语句的加锁范围:利用上面的加锁规则,这个语句的加锁范围是主键索引上的 (0,5]、(5,10]和 (10, 15)。也就是说,id=15 这一行,并没有被加上行锁。为什么呢?说加锁单位是 next-key lock,都是,但是这里用到了优化 2,,所以 next-key lock 退化为了间隙锁 (1原创 2023-02-19 17:13:00 · 784 阅读 · 1 评论 -
Day893.MySQL 实例健康状态检测方法 -MySQL实战
检测一个 MySQL 实例健康状态的几种方法,以及各种方法存在的问题和演进的逻辑。看完后可能会觉得,select 1 这样的方法是不是已经被淘汰了呢,但实际上使用非常广泛的 MHA(Master High Availability),默认使用的就是这个方法。MHA 中的另一个可选方法是只做连接,就是 “如果连接成功就认为主库没问题”。选择这个方法的很少。其实,每个改进的方案,都会增加额外损耗,并不能用“对错”做直接判断,需要你根据业务实际情况去做权衡。原创 2023-02-18 19:58:29 · 1244 阅读 · 3 评论 -
Day892.MySql读写分离过期读问题 -MySQL实战
这几种方案中,有的方案看上去是做了妥协,有的方案看上去不那么靠谱儿,但都是有实际应用场景的,需要根据业务需求选择。即使是最后等待位点和等待 GTID 这两个方案,虽然看上去比较靠谱儿,但仍然存在需要权衡的情况。如果所有的从库都延迟,那么请求就会全部落到主库上,这时候会不会由于压力突然增大,把主库打挂了呢?其实,在实际应用中,这几个方案是可以混合使用的。比如,先在客户端对请求做分类,区分哪些请求可以接受过期读,而哪些请求完全不能接受过期读;原创 2023-02-17 20:14:23 · 498 阅读 · 1 评论 -
Day891.一主多从的切换正确性 -MySQL实战
Hi,我是阿昌,今天学习记录的是关于一主多从的切换正确性的内容。大多数的互联网应用场景都是读多写少,因此负责的业务,在发展过程中很可能先会遇到读性能的问题。一主多从的查询逻辑正确性的方法。如图 1 所示,就是一个基本的一主多从结构。图中,虚线箭头表示的是主备关系,也就是 A 和 A’互为主备, 从库 B、C、D 指向的是主库 A。一主多从的设置,一般用于读写分离,主库负责所有的写入和一部分读,其他的读请求则由从库分担。在一主多从架构下,主库故障后的主备切换问题。如图 2 所示,就是主库发生故障。原创 2023-02-17 00:13:28 · 686 阅读 · 0 评论 -
Day890.MySQL备库并行复制能力 -MySQL实战
为什么要有多线程复制呢?这是因为单线程复制的能力全面低于多线程复制,对于更新压力较大的主库,备库是可能一直追不上主库的。从现象上看就是,备库上 seconds_behind_master的值越来越大。如果是 DBA,就需要根据不同的业务场景,选择不同的策略;如果是业务开发人员,也希望你能从中获取灵感用到平时的开发工作中。从这些分析中,也会发现大事务不仅会影响到主库,也是造成备库复制延迟的主要原因之一。因此,在平时的开发工作中,建议尽量减少大事务操作,把大事务拆成小事务。原创 2023-02-15 23:49:44 · 502 阅读 · 0 评论 -
Day889.MySQL高可用 -MySQL实战
Hi,我是阿昌,今天学习记录的是关于MySQL高可用的内容。正常情况下,只要主库执行更新生成的所有 binlog,都可以传到备库并被正确地执行,备库就能达到跟主库一致的状态,这就是最终一致性。但是,MySQL 要提供高可用能力,只有最终一致性是不够的。为什么这么说呢?原创 2023-02-15 01:25:49 · 341 阅读 · 0 评论 -
Day888.MySQL是怎么保证主备一致的 -MySQL实战
Hi,我是阿昌,今天学习记录的是关于的内容。MySQL 能够成为现下最流行的开源数据库,binlog 功不可没。在最开始,MySQL 是以容易学习和方便的高可用架构,被开发人员青睐的。而它的几乎所有的高可用架构,都直接依赖于 binlog。虽然这些高可用架构已经呈现出越来越复杂的趋势,但都是从最基本的一主一备演化过来的。理解了背后的设计原理,也可以从业务开发的角度,来借鉴这些设计思想。原创 2023-02-13 22:26:00 · 562 阅读 · 1 评论 -
Day887.MySQL写入binlog和redolog的流程机制 -MySQL实战
Hi,我是阿昌,今天学习记录的是关于的内容。只要 redo log 和 binlog 保证持久化到磁盘,就能确保 MySQL 异常重启后,数据可以恢复。那redo log 的写入流程是怎么样的,如何保证 redo log 真实地写入了磁盘。流程。原创 2023-02-13 01:19:49 · 901 阅读 · 0 评论 -
Day886.MySQL的“饮鸩止渴”提高性能的方法 -MySQL实战
以业务高峰期的性能问题为背景,介绍了一些紧急处理的手段。这些处理手段中,既包括了粗暴地拒绝连接和断开连接,也有通过重写语句来绕过一些坑的方法;既有临时的高危方案,也有未雨绸缪的、相对安全的预案。在实际开发中,也要尽量避免一些低效的方法,比如避免大量地使用短连接。同时,如果做业务开发的话,要知道,连接异常断开是常有的事,代码里要有正确地重连并重试的机制。DBA 虽然可以通过语句重写来暂时处理问题,但是这本身是一个风险高的操作,做好SQL 审计可以减少需要这类操作的机会。原创 2023-02-11 20:55:29 · 627 阅读 · 2 评论 -
Day885.NextKeyLock加锁规则 -MySQL实战
同时,可重复读隔离级别遵守两阶段锁协议,所有加锁的资源,都是在事务提交或者回滚的时候才释放的。在最后的案例中,清楚地知道 next-key lock 实际上是由间隙锁加行锁实现的。如果切换到读提交隔离级别 (read-committed) 的话,过程中去掉间隙锁的部分,也就是只剩下行锁的部分。其实读提交隔离级别在外键场景下还是有间隙锁,相对比较复杂,我们今天先不展开。原创 2023-02-11 00:24:57 · 897 阅读 · 0 评论 -
Day884.幻读 -MySQL实战
提到了全表扫描的加锁方式。发现即使给所有的行都加上行锁,仍然无法解决幻读问题,因此引入了间隙锁的概念。碰到过很多对数据库有一定了解的业务开发人员,他们在设计数据表结构和业务 SQL 语句的时候,对行锁有很准确的认识,但却很少考虑到间隙锁。最后的结果,就是生产库上会经常出现由于间隙锁导致的死锁现象。行锁确实比较直观,判断规则也相对简单,间隙锁的引入会影响系统的并发度,也增加了锁分析的复杂度,但也有章可循。实际上,这里 session B 和 session C 的 insert 语句都会进入锁等待状态。原创 2023-02-09 23:51:39 · 477 阅读 · 1 评论 -
Day883.只查一行的语句,也执行这么慢? -MySQL实战
Hi,我是阿昌,今天学习记录的是关于的内容。一般情况下,讲到查询性能优化,你首先会想到一些复杂的语句,想到查询需要返回大量的数据。但有些情况下,“查一行”,也会执行得特别慢。需要说明的是,如果 MySQL 数据库本身就有很大的压力,导致数据库服务器CPU 占用率很高或,这种情况下所有语句的执行都有可能变慢,不属于这次的讨论范围。为了便于描述,还是构造一个表,基于这个表来说明今天的问题。这个表有两个字段 id 和 c,并且在里面插入了 10 万行记录。原创 2023-02-08 23:05:30 · 715 阅读 · 1 评论 -
Day882.隐式函数转换索引问题 -MySQL实战
对索引字段做函数操作,可能会破坏索引值的有序性,因此优化器就决定放弃走树搜索功能。第二个例子是隐式类型转换,第三个例子是隐式字符编码转换,它们都跟第一个例子一样,因为要求在索引字段上做函数操作而导致了全索引扫描。MySQL 的优化器确实有“偷懒”的嫌疑,即使简单地把 where id+1=1000 改写成 where id=1000-1 就能够用上索引快速查找,也不会主动做这个语句重写。因此,每次业务代码升级时,把可能出现的、新的 SQL 语句 explain 一下,是一个很好的习惯。原创 2023-02-07 23:03:25 · 609 阅读 · 1 评论 -
Day881.临时表排序 -MySQL实战
如果直接使用 order by rand(),这个语句需要 Using temporary 和 Using filesort,查询的执行代价往往是比较大的。所以,在设计的时候要尽量避开这种写法。尽量将业务逻辑写在业务代码中,让数据库只做“读写数据”的事情。因此,这类方法的应用还是比较广泛的。上面的随机算法 3 的总扫描行数是 C+(Y1+1)+(Y2+1)+(Y3+1),实际上它还是可以继续优化,来进一步减少扫描行数的。问题是,如果你是这个需求的开发人员,你会怎么做,来减少扫描行数呢?原创 2023-02-06 20:45:30 · 873 阅读 · 1 评论 -
Day880.OrderBy工作原理 -MySQL实战
MySQL 里面 order by 语句的几种算法流程。在开发系统的时候,总是不可避免地会使用到 order by 语句。心里要清楚每个语句的排序逻辑是怎么实现的,还要能够分析出在最坏情况下,每个语句的执行对系统资源的消耗,这样才能做到下笔如有神,不犯低级错误。全字段排序找到满足条件的所有行,取出字段,在内存中对返回字段进行排序,最后返回需要的行数量rowid 排序找到满足条件的所有行,取出对应id和对应排序的字段,在内存中对字段进行排序,返回需要的行数量用id查询出结果覆盖索引排序。原创 2023-02-05 17:53:52 · 587 阅读 · 2 评论 -
Day879.数据库日志和索引相关问题 -MySQL实战
创建了一个简单的表 t,并插入一行,然后对这一行做修改。这时候,表 t 里有唯一的一行数据 (1,2)。会看到这样的结果:结果显示,匹配 (rows matched) 了一行,修改 (Changed) 了 0 行。更新都是先读后写的,MySQL 读出数据,发现 a 的值本来就是 2,不更新,直接返回,执行结束;MySQL 调用了 InnoDB 引擎提供的“修改为 (1,2)”这个接口,但是引擎发现值与原来相同,不更新,直接返回;原创 2023-02-04 21:24:57 · 782 阅读 · 2 评论 -
Day878.count(*)问题 -MySQL实战
把计数放在 Redis 里面,不能够保证计数和 MySQL 表里的数据精确一致的原因,是这两个不同的存储构成的系统,不支持分布式事务,无法拿到精确一致的视图。而把计数值也放在 MySQL 中,就解决了一致性视图的问题。InnoDB 引擎支持事务,利用好事务的原子性和隔离性,就可以简化在业务开发时的逻辑。这也是 InnoDB 引擎备受青睐的原因之一。用了事务来确保计数准确。由于事务可以保证中间结果不被别的事务读到,因此修改计数值和插入新记录的顺序是不影响逻辑结果的。原创 2023-02-03 23:08:52 · 680 阅读 · 0 评论 -
Day877.数据空洞 -MySQL实战
现在你已经知道了,如果要收缩一个表,只是 delete 掉表里面不用的数据的话,表文件的大小是不会变的,还要通过 alter table 命令重建表,才能达到表文件变小的目的。重建表的两种实现方式,Online DDL 的方式是可以考虑在业务低峰期使用的,而 MySQL 5.5 及之前的版本,这个命令是会阻塞 DML 的,这个你需要特别小心。一个表 t 文件大小为 1TB;对这个表执行 alter table t engine=InnoDB;原创 2023-02-03 00:06:52 · 688 阅读 · 0 评论 -
Day876.redolog刷盘问题 -MySQL实战
利用 WAL 技术,数据库将随机写转换成了顺序写,大大提升了数据库的性能。但是,由此也带来了内存脏页的问题。脏页会被后台线程自动 flush,也会由于数据页淘汰而触发 flush,而刷脏页的过程由于会占用资源,可能会让你的更新和查询语句的响应时间长一些。一个内存配置为 128GB、innodb_io_capacity 设置为 20000 的大规格实例,正常会建议你将 redo log 设置成 4 个 1GB 的文件。原创 2023-02-01 22:08:07 · 1036 阅读 · 0 评论 -
Day875.怎么给字符串字段加索引 -MySQL实战
直接创建完整索引,这样可能比较占用空间;创建前缀索引节省空间,但会增加查询扫描次数,并且不能使用覆盖索引;倒序存储,再创建前缀索引,用于绕过字符串本身前缀的区分度不够的问题,不支持范围扫描;创建hash 字段索引查询性能稳定,有额外的存储和计算消耗,跟第三种方式一样,都不支持范围扫描。在实际应用中,你要根据业务字段的特点选择使用哪种方式。如果你在维护一个学校的学生信息数据库,学生登录名的统一格式是”学号 @gmail.com", 而学号的规则是:十五位的数字其中前三位是所在城市编号。原创 2023-01-31 22:01:33 · 692 阅读 · 0 评论 -
Day874.MySQL索引选择出错问题 -MySQL实战
优化器存在选错索引的可能性。对于由于索引统计信息不准确导致的问题,可以用来解决。而对于其他优化器误判的情况,可以在应用端用来强行指定索引,也可以通过修改语句来引导优化器,还可以通过增加或者删除索引来绕过这个问题。可能会说,后面的几个例子,怎么都没有展开说明其原理。面对的是 MySQL 的 bug,每一个展开都必须深入到一行行代码去量化,实在不是在这里应该做的事情。原创 2023-01-30 21:34:47 · 562 阅读 · 0 评论 -
Day873.普通索引&唯一索引的选择 -MySQL实战
由于唯一索引用不上 change buffer 的优化机制,因此如果业务可以接受,从性能角度出发我建议优先考虑非唯一索引。通过图 2 可以看到,change buffer 一开始是写内存的,那么如果这个时候机器掉电重启,会不会导致 change buffer 丢失呢?change buffer 丢失可不是小事儿,再从磁盘读入数据可就没有了 merge 过程,就等于是数据丢失了。会不会出现这种情况呢?原创 2023-01-29 21:53:50 · 588 阅读 · 0 评论 -
Day872.事务间是否需要隔离 -MySQL实战
小结InnoDB 的行数据有多个版本,每个数据版本有自己的 row trx_id,每个事务或者语句有自己的一致性视图。普通查询语句是一致性读,一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。对于可重复读,查询只承认在事务启动前就已经提交完成的数据;对于读提交,查询只承认在语句启动前就已经提交完成的数据;而当前读,总是读取已经提交完成的最新版本。为什么表结构不支持“可重复读”?这是因为表结构没有对应的行数据,也没有 row trx_id,因此只能遵循当前读的逻辑。原创 2023-01-29 00:46:58 · 410 阅读 · 0 评论 -
Day871.行锁 -MySQL实战
MySQL 的行锁,涉及了两阶段锁协议、死锁和死锁检测这两大部分内容。其中,以两阶段协议为起点,讨论了在开发的时候如何安排正确的事务语句。这里的原则给建议是:如果事务中需要锁多个行,要把最可能造成锁冲突、最可能影响并发度的锁的申请时机尽量往后放。但是,调整语句顺序并不能完全避免死锁。所以引入了死锁和死锁检测的概念,以及提供了三个方案,来减少死锁对数据库的影响。减少死锁的主要方向,就是控制访问相同资源的并发事务量。第一种,直接执行 delete from T limit 10000;原创 2023-01-28 00:10:35 · 626 阅读 · 0 评论