MySQL性能优化盲区（高并发环境下，事务内的数据先更新还是先查询？）
近期看到了一个前阿里资深开发的学术分析视频：高并发环境下，一个事务内有更新操作另有查询操作，那是先更新好，还是先无锁查询好？
仅70秒的视频，深感学问太深，但是海哥讲的有待补充，于是写下了这篇文章，作为补充。
鸣谢：前阿里资深开发极海Channel的技术分享。
先说答案
这是个开放性的问题，必须看业务场景，抛开业务场景谈架构设计，都是耍流氓。
[*]场景1：假如update语句的参数操作依靠于查询操作，那么必须先查询，再更新，否则update语句的参数都凑不齐。
[*]场景2：假如update语句的参数操作不依靠于查询操作，但两个操作的是一张表，业务逼迫要求select获取的数据必须是最新的，则也需要先更新再读取。
[*]场景3：以上两种环境除外，则优先思量先查询再更新。
场景1受参数限定，顺序毋庸置疑。
场景2受业务限定，顺序毋庸置疑。
场景3是为了性能优化，才去选择的方案。
测试表
CREATE TABLE `cs` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`num` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '数字列',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO `temp`.`cs` (`id`, `num`) VALUES (1, 1);
INSERT INTO `temp`.`cs` (`id`, `num`) VALUES (2, 2);
INSERT INTO `temp`.`cs` (`id`, `num`) VALUES (3, 3);
假设场景2的代码如下：
start transaction;
update cs set num = 13 where id = 1;
SELECT * FROM `cs`;
commit;
场景3的代码如下：
start transaction;
SELECT * FROM `cs`;
update cs set num = 13 where id = 1;
commit;对场景2，同一个事务内，先实行update，事务没提交，能读取到最新的数据吗？
能。
步骤SQL补充1start transaction;开启事务2select num from cs where id = 1;num值是13update cs set num = 12 where id = 1;更新num值为124select num from cs where id = 1;num值是125rollback;回滚事务都说不加锁的select是快照读，为什么select还能读取当前事务的最新数据？
根据现象反推，个人认为：
不加锁的select是快照读，针对的是事务之外的不加锁的select，MySQL RR的隔离级别，只要更新的事务未提交，别的事务就读取不到更改的新数据。
当前事务内的select，就是不加锁的当前读（个人称呼）。当然，真正的当前读概念是为了包管读的最新数据，必须加锁。
对场景3的性能优化原理分析
得知道4个前提：
[*]场景3的实现，不会影响业务和开发。
[*]因为select没有加S或X锁，所以不会壅闭。
[*]update语句会上X锁，可能是行锁、间隙锁，或者表锁（受索引、where条件的影响），所以并发请求过来后，别的事务的update有被壅闭的可能。
[*]用事务，就需要InnoDB引擎，InnoDB引擎支持行级锁，假如确定update的X锁，在并发环境下锁定的范围没有交集，这种优化方式起不到作用，这意味着不会壅闭。
[*]假如先更新再查询：
分析原理：
事务A的update语句会上锁，并发环境下壅闭事务B的update操作，假如事务A的select是个慢查询，事务A的X锁开释需要等到事务提交，而不是update语句本身实行完毕，这就意味着事务A select的环节，X锁也未开释，从而壅闭别的事务的update，降低性能。
实操模拟：
步骤事务A事务B补充1start transaction;start transaction;两边开启事务，模拟并发请求2update cs set num = 1234 where id = 1;update cs set num = 1234;两个差别where范围的update，模拟线上的场景3/壅闭事务A的行X锁，壅闭了事务B的表X锁4select * from cs where id = 1;壅闭这一步很重要，优化就是为了制止这一步的壅闭耗时，特别是慢查询5commit;壅闭事务A提交6/select * from cs where id = 1;事务A完成，事务B不会再壅闭了7/commit;结束事务B
[*]假如先查询再更新：
分析原理：事务A的select语句不会上锁，此时势务不会导致事务B壅闭，假如实行到事务A实行到update，才归去上X锁，直到事务提交锁资源开释，纵然事务A的select是一个慢查询，也不会加大事务A开释锁资源的事件，进而减少事务B的壅闭时间。
实操模拟：
步骤事务A事务B补充1start transaction;start transaction;两边开启事务，模拟并发请求2select * from cs where id = 1;select * from cs where id = 1;两个事务不加锁不壅闭，这一步的壅闭时间省了3update cs set num = 1234 where id = 1;update cs set num = 1234;两个事务更新4/壅闭两个X锁范围有冲突，壅闭5commit;壅闭事务A提交6/commit;事务B提交所以说，只要业务允许，调解SQL语句的实行顺序，高并发环境下，就能得到不小的性能提升，但是这一点很容易忽略。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]