开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2310人左右 1 + 2 + 3 + 4 +5+6） 新人分配到6群,准备建立7 群。*（1 2 3 4 5 均没有空位了，请不要在问了谢谢）
最近群里一个知名的软件服务商的领导，说他的系统服务的客户很多还在用MySQL5.6,5.7 然后群里说还有用5.5的了。哎MySQL 的老版本的用户不少，大部分还在MySQL 5.7上转悠。说是升级的热情不高，当然这与ORACLE 对MySQL的8.0版本的“不负责”，有关，也与不少用户目前使用MySQL5.7并没有遇到问题有关。
但这里提示能升级MySQL的同学还是进来升级,MySQL到8.018版本以上（不包括8.029）。因为最近我们出现了一个严重的MySQL的故障，版本是MySQL 5.7.28,Official 版本。
系统已经持续运行了有5-6年了，没有问题，但突然一天CPU升高，接近100%，并且持续的高，我们抓取了慢查询日志，发现其中有一个SQL 与这个问题有关，随机我们进行了测试，执行计划完全走了索引，一个这样简单的SQL 竟然要90-120秒，这让我们不可思议。随即我们将SQL 在从库进行了测试，发现从库运行这个SQL的速度异常的快只要0.006秒。
select
distinct RES.*,
AR.ID_ as VAR_ID_,
AR.NAME_ as VAR_NE_,
AR._TYPE_ as V_TYPE_,
AR._ as VAR_REV_,
AR.C_INST_ID_ as VR_PC_ID_,
AR.CUT_ID_ as VR_EXECUID_,
AR.K_ID_ as R_SK_ID_,
AR.EA_ID_ as VAR_BAY_ID_,
AR.BLE_ as VAR_DLE_,
AR.T_ as VR_XT_,
AR.T2_ as VR_TET2_,
AR.T_UPDD_TI_ as VAR_ST_TED_ME_,
AR.G_ as V_LG_
from
tcn.AC_HI_TST RE
left outer join tcn.NST AR ON RE.PNST_ID_ = AR.EXON_ID_
and VAR.TK_ID_ is null
WHERE
RES.ID_ = '173878637'
order by
VAR.LAST_UED_TIME_ asc
LIMIT
20000 OFFSET 0;
这里最大的问题是他有主从库，主库是运行的是不OK的，但是从库运行是非常快的，同样的数据，同样的SQL，进行explain的时候也是同样的执行计划。
到底是为什么，通过show engine innodb status,和各种系统表也分析了当前写库是否有大事务，或者表被霸占，或大事务等情况，统统的没有，就是慢，慢，慢 fack!!!
冷静下来分析
1 主库和从库数据一致，语句一致，执行计划一致
2 在主库实际运行语句最快1分30秒 ，在从库运行0.005秒。
此时在想，如果是MySQL8 就好了，我们可以使用explain format = 多种显示的方式，并且还能trace 具体的执行计划，而不是在这里看着简单的执行计划，并看着业务部门在问到底怎么回事。在问题分析这块，MYSQL5.7就是一个傻子。
然后只能从语句上下手，尝试，语句中有两个点
1 ORDER BY
2 limit N,M
因为MySQL有一个致命的问题这在8.0后也有类似的问题，但在高版本将这个问题的参数默认给关闭了，ORDER BY LIMIT 执行效率的问题。
问题主要表现在 where condition order by A limit N 这样的语句，由于MYSQL5.7默认是打开 prefer_ordering_index 也就是在操作的时候，由于limit N 的值比较小，导致查询分析器去走ORDER BY 字段上的索引，而放弃更适合的索引。
摆在我面前的有几个方案
1 去设置optimizer_switch='prefer_ordering_index=OFF'
2 尝试添加一个比现在索引权重更大的索引 （需要看条件，不是每次都能行）
3 强制语句使用 hint
由于这个.28的版本比较老，记得应该是.33后的MySQL才可以添加 prefer_ordering_index参数所以第一个选择的方案不可以。
那么就需要尝试剩下的方案，我先尝试第三个方案，的确在强制hint index后，语句执行的速度┗|｀O′|┛ 嗷，的一下子就快了，0.006秒，看来的确是和语句执行没有走正确的索引有关，配合监控中的执行语句的时候iops就超高，估计是是3千500万的表在进行全表的扫描。尝试了多次，只要语句执行不HINT，IOPS 就超高。
但是让开发去给你改语句，虽然开发说可以，但觉得对不起开发，这数据库的稳定性也忒差了，我尝试第二个方式，正好这个查询中在left join 中带有一个其他的条件，那么我就舱室重建索引，将原来的单字段的索引，改成复合的字段，这样从查询计划的实现上也是有利于数据查询的，在添加这个复合的索引后，再次尝试语句，速度也是┗|｀O′|┛ 嗷的一下子蹦到 0.005秒。
先对这些方案，还是通过添加索引来进行问题的解决，让几方更能接受，后面打算对mysql的小版本进行升级，当然如果能推动往 MYSQL 8.018的版本上进行升级最好是 8.025就更好了，那么后续的一些DDL等操作也会更顺手，同时对于GROUP BY的语句执行的方式有了更大的优化，在低版本MYSQL无法运行的复杂的SQL，在8.025以上的版本运行也会更加的顺畅。
官方对此知识的文档
https://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html
置顶文章：
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
云原生数据库是一场闹剧，还是数据库市场的程咬金
PolarDB 从节点Down机后，引起的主从节点强一致的争论
临时工说：数据库和周边做不好原因是产品经理的锅？读从OtterTune的倒下说起-有感
往期热门文章：
临时工说: 网友问35岁就淘汰，我刚入行DBA 怎么办？临时工访谈：问金融软件开发总监 哪些业务不用传统数据库PostgreSQL 15 16 小版本更新信息小结 版本更新是不是挤牙膏
临时工访谈：临时工 写了6年多公众号赚了多少钱？
MongoDB 的一张“大字报” 服务客户，欢迎DISS
MongoDB 聚合怎么写，更复杂的聚合案例
MySQL 8.0 小版本更新要点，那个小版本更稳定（8.0.24-8.0.37）
SQL SERVER 2022 针对缓存扫描和Query Store 的进步，可以考虑进行版本升级
有思想的人，在这个年代会很痛苦？躺平还是醒着都无所谓了
MYSQL 版本迁移带来 严重生产事故“的”分析
PolarDB Serverless POC测试中有没有坑与发现的疑问
临时工访谈：PolarDB Serverless 发现“大”问题了 之 灭妖记 续集
临时工访谈：庙小妖风大-PolarDB 组团镇妖 之 他们是第一
PolarDB for PostgreSQL 有意思吗？有意思呀
PolarDB Serverless POC测试中有没有坑与发现的疑问
MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验
临时工访谈：从国产数据库 到 普罗大众的产品 ！与在美国创业软件公司老板对话
PostgreSQL 如何通过工具来分析PG 内存泄露
MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验
临时工访谈：我很普通，但我也有生存的权利，大龄程序员 求职贴临时工说: 快速识别 “海洋贝壳类” 数据库方法速递临时工说：国产 数据库 销售人员 图鉴临时工说：DBA 是不是阻碍国产数据库发展的毒瘤 ，是不是？从国产DB老专家的一条留言开始 （其实更好看的是文章下方的留言）
感谢 老虎刘 刘老师 对 5月20日 SQL 问题纠正贴 ---PostgreSQL 同一种SQL为什么这样写会提升45%性能
PostgreSQL 同一种SQL为什么这样写会提升45%性能 --程序员和DBA思维方式不同决定
MongoDB 不是软柿子，想替换就替换
PostgreSQL 熊灿灿一句话够学半个月 之 KILL -9
MongoDB 挑战传统数据库聚合查询，干不死他们的
临时工说：国内数据库企业存活 “三板斧”
临时工访谈：庙小妖风大-PolarDB 组团镇妖 之 他们是第一 （阿里云组团PK笔者实录）
临时工访谈：金牌 “女” 销售从ORACLE 转到另类国产数据库 到底 为什么？
临时工访谈：无名氏意外到访-- 也祝你好运（管理者PUA DBA现场直播）
临时工说：搞数据库 光凭的是技术，那DBA的死多少次？
PostgreSQL 分组查询可以不进行全表扫描吗？速度提高上千倍？临时工说：分析当前经济形势下 DBA 被裁员的根因
PostgreSQL PG_DUMP 工作失败了怎么回事及如何处理MySQL 八怪（高老师）现场解决问题实录
PostgreSQL 为什么也不建议 RR隔离级别，MySQL别笑临时工访谈：OceanBase上海开大会，我们四个开小会 OB 国产数据库破局者
临时工说：OceanBase 到访，果然数据库的世界很卷，没边临时工访谈：恶意裁员后，一个国产数据库企业程序员的心声
临时工说：上云后给 我一个 不裁 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信息类网站文章翻译，等，希望能和您共同发展。
