开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2260人左右 1 + 2 + 3 + 4 +5） 新人奖直接分配到5群,5群超过300 已建立6群，另欢迎 OpenGauss 的技术人员加入。
最近感觉，的确是不够用，手指头不够用，群里每天都有有意思的事情，正在准备下一步临时工访谈，一个更有意思刺激的故事，这就遇上群里高老师现场解决问题，高老师是MySQL业界的实战派，出现在群里呢，属于老神仙出山你算不出那天来,估计每天都是忙到想撞墙的地步。
实录开始：
explain format=json SELECT DISTINCT b.id,a.sid,a.gid,a.deal1id,a.deal2id,a.deal3id,b.qty,b.costprice,b.costmoney,b.noinqty,b.nooutqty,b.realqty,b.status,a.profileid,b.noreceiveqty,b.norejectqty,u.fullname ufullname,gu.unitrate,IFNULL(price.refercostprice,'') refercostprice,IFNULL(price.recbuyprice,'') AS recbuyprice,g.enlarge_qty,s.allownegativestockFROM erp_bill_sale aLEFT JOIN `erp_goods_stock_deal` b ON a.profileid=b.profileid AND a.sid=b.sid AND a.gid=b.gid AND a.deal1id=b.deal1id AND a.deal2id=b.deal2id AND a.deal3id=b.deal3idINNER JOIN bas_goods g ON a.gid = g.gidINNER JOIN bas_goods_unit gu ON g.gid = gu.gid AND gu.uid=g.saleuid AND a.profileid = gu.profileid AND gu.flag=0INNER JOIN bas_unit u ON gu.uid = u.uid INNER JOIN bas_goods_unit curgu ON a.gid=curgu.gid AND curgu.unittype=1 AND a.profileid = curgu.profileidLEFT JOIN bas_goods_price pr ON pr.gid=a.gid AND pr.deal1id =a.deal1id AND pr.deal2id=a.deal2id AND pr.deal3id=a.deal3idLEFT JOIN bas_plu plu ON plu.profileid=pr.profileid AND plu.skuid=pr.skuid AND plu.uid=curgu.uidLEFT JOIN bas_plu_price price ON price.pluid=plu.pluid AND price.profileid=plu.profileidLEFT JOIN bas_store s ON s.sid = b.sid AND s.profileid=b.profileid WHERE a.profileid=200007292 AND a.billid = 1066434223 AND plu.flag =0；
语句参见上图，这是群里一个同学提供的，然后这个同学提出语句在执行中出现问题，
1 这个语句单独执行只需要 1秒2 这个语句放到事务里面需要10分组的样子，才能执行完毕。
这里临时工也稍微的围观和凑合了一下，针对这个同学给出了，事务内和事务外部的TRACE 的文件。（基于隐私和我也没有和这个同学问是否可以把名字 SHOW 出来，只能隐去）,这里trace 的文件太大了，我没有办法贴到这里，贴完，估计诸位的手机流量都要爆了。
我就把我昨天，分析这两个TRACE 文件的截图贴上来，方便诸位了解相关的情况。我这里把不一致的部分贴上来。8400多行我也不能都截图，那样电脑也的爆掉，所以只能截取两个语句在比对中不同的部分。
一开始是没有什么不同的，到后面，在行评估的部分开始，就有不同了。这里说梦一下，在各位看官左手的文档是没有事务的，在右手的是在事务中的。
开始出不同了，明显在不在事务内的语句，执行的时候，在使用索引评估时的行部分，有了较大的差异，可以明显看出，在非事务的rows 评估要比事务内的查询语句的 rows 行评估要大一倍，自然COST 也就不一致了
在下面的大部分TRACE 的文件比对的部分，都是有类似的情况，大表基本上行数是没有变化的，所有COST值没有相关的大的变化，而只要涉及到一些ROWS 较小的时候，就会产生较大的差异。
后面我也是是在截图不下去，我才截图5分之一，大部分情况都是这样，到后面整体执行计划部分就都变味了。
到这里结束，其中有一个同学提出，事务隔离级别与锁的问题，导致的执行计划方面的不同。
同时高老师也提出一个问题，关于在事务内，你的事务是否对这些表有变化的问题，比如你删除了表里面的数据，或者UPDATE 或者做其他的操作等。
那个同学回答，是的，的确在事务中有相关的对于表的更改。
整体的问题解决结束。
后面同学又拿出相关的执行计划，下面的是事务外的
这张是事务内的
可以很清晰的看到，相关的索引在两个部分里面选择是不同的。
http://mysql.taobao.org/monthly/2020/03/08/
另外还有一个问题关于这个同学提出的，HINT 部分的问题，高老师也给出图了。
这里补充一些信息，方便不清楚的同学理解， 在MYSQL 中是可以进行HINT的，当多表在进行JOIN 的时候，使用了STRAIGHT_JOINDE 时，MySQL 按照他在查询中的列出的链接顺序链接表，根据不同的链接测量的成本估算对标进行重新的排序，通过straight_join来强制MYSQL按照指定的顺序来进行表的链接顺序的重新制定。
到此为止，整体的事情基本说明白了。
总结一下，
1 事务中，如果查询处于整体事务的下方，同时上方又有相关对查询表的一些数据的修改，那么当达到了一定的表的修改的数量级别，就会对表的统计分析进行变更。
2 在事务中，表的统计分析的数据变更后，整体的执行计划必然会重新调整，如上图，那么就会导致查询计划的变化。出现提出问题同学中关于事务内核事务外部执行同样的语句，但执行的时间的变化。
处理方法是，找到最优的执行方式，并对在事务中执行的查询语句添加HINT 来解决相关的问题。
————————————————————————————
后记：大佬们在解决问题的时候，主要是短平快，他的目的是解决问题，而不是在短时间去分析问题，我们在提问题的时候，应该给付充足的信息如同提出问题的同学，给出的信息比较详细，方便快速定位问题解决问题。
再次感谢 高老师 （八怪）
往期热门文章：
临时工说：经济规律解读ORACLE 工资低 --读 Roger 数据库专栏
PostgreSQL 为什么也不建议 RR隔离级别，MySQL别笑
临时工访谈：OceanBase上海开大会，我们四个开小会 OB 国产数据库破局者
临时工说：OceanBase 到访，果然数据库的世界很卷，没边临时工访谈：恶意裁员后，一个国产数据库企业程序员的心声
临时工访谈：国产数据库裁员失业中，但我仍然积极乐观的DBA
临时工访谈：45岁IT女领导 失业 后的人生下半部
临时工访谈：TM 这些年 我都培训了什么临时工说：上云后给 我一个 不裁 DBA的理由临时工说：腾讯云，阿里云故障 “核爆炸” 后持续的影响
临时工说：三次封禁后的文章--技术文章怎么写，我有罪PolarDB for PostgreSQL 有意思吗？有意思呀PostgreSQL 玩PG我们是认真的，vacuum 稳定性平台我们有了临时工说：裁员裁到 DBA 咋办 临时工教你 套路1 2 3PolarDB 搞那么多复杂磁盘计费的东西，抽筋了吗？临时工说：OceanBase 到访，果然数据库的世界很卷，没边MONGODB ---- Austindatabases 历年文章合集MYSQL --Austindatabases 历年文章合集POSTGRESQL --Austindatabaes 历年文章整理POLARDB -- Ausitndatabases 历年的文章集合PostgreSQL 查询语句开发写不好是必然，不是PG的锅
SQL SERVER 如何实现UNDO REDO 和PostgreSQL 有近亲关系吗
MongoDB 2023纽约 MongoDB 大会 -- 我们怎么做的新一代引擎 SBE Mongodb 7.0双擎力量（译）
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB 双机热备那篇文章是 “毒”
MongoDB 会丢数据吗？在次补刀MongoDB 双机热备
临时工说：从人性的角度来分析为什么公司内MySQL 成为少数派，PolarDB 占领高处
POLARDB 到底打倒了谁 PPT 分享 （文字版）
PostgreSQL 字符集乌龙导致数据查询排序的问题，与 MySQL 稳定 "PG不稳定"
PostgreSQL Patroni 3.0 新功能规划 2023年 纽约PG 大会 （音译）
Austindatabases 公众号，主要围绕数据库技术（PostgreSQL, MySQL, Mongodb, Redis, SqlSERVER，PolarDB, Oceanbase 等）和职业发展，国外数据库大会音译,国外大型IT信息类网站文章翻译，等，希望能和您共同发展。截止今日发布1127篇内容
