1、问题复现昨天在微信群里有人发了一个问题，觉得不可思议，认为是MySQL的Bug，但随后题主贴出执行计划，一看执行计划就知晓问题点了，但我觉得此问题可以扩展几个重要的知识点，我用我的本地数据做了复现

今天在生产环境上遇到一个SQL明明join表的关联字段上有索引，MySQL就是不走，则于版本又是8.0.13之前的版本。没有hashjoin只能走BNL让整个SQL奇慢无比执行计划是这样的执行

1、官网介绍ConditionFilteringFlagsconditionfanoutfilter(defaulton)Controlsuseofconditionfilteri

这个是事后的监控图快中午的时候，被客户群消息淹没。反馈所有业务动作都变得很慢。一、排查问题运维登陆服务器监控。发生一台数据库实例如上图，CPU与内存双双被打满基于事故先恢复后排查的原则，运维kill了

对公司研发进行了几场培训，效果很好，一般慢查询他们已经能够直接优化了，但今天又收到研发的一个慢SQL,看执行计划很好，但执行起来很慢。我拿到SQL展开研究，最后发现强制走全表会快得多。我们一起来看看这

今天遇到一个索引失效问题很有意思，也有一个小小的知识点以前没有注意，特写此文记录一下我们常规遇到索引失效有可能下面几种情况1、左’%'查询2、隐式转换3、使用联合索引不符合最左匹配4、字符集编码不一致

1、收到问题今天收到研发人员咨询一个单表查询SQL在测试环境查不出来，咨询我有没有优化方案需求大概是这样的报表需要呈现每种不同类型单据，每天第一单交易中止数据类似于统计每个班人总成绩排名第一的性别为女

1、来自于生产事故的压力在一次做生产环境DDL的操作中，误判了产生的影响，造成了大量的堵塞（查询了需要DDL的表，发现表行数很小，行数在万行以下，所以认为DDL会很快完成，但没有判断出这个表的并发度，

1、发现问题开发拿到一个SQL问我，为什么一个SQL得不到想要的结果原本身SQL较复杂，掩盖了简单的问题。这里我用测试数据做一个场景复现，并深入了解问题背后的MySQL原理2、问题复现创建测试表，并插

1、发现问题昨天跟踪线上慢SQL,发现有一条SQL始终走全表扫描，造成查询非常慢，查询时间达到了10分钟。2、问题复现SQL语句非常长。估计有上百行。这里就不贴原语句了，通过分析，找到了根本原因，我这

1、问题复现巡查生产环境慢SQL日志，发现一条很简单的语句需要执行35S，而改变一下驱动表只需要0.047S,性能相差744倍执行35秒的原语句explainSELECTA.gidFROMB

1、问题今天刷墨天轮的问答，刷到一个优化问题原问题SQL求助，如下sql怎么改写可以快起来以下为原问题/tabs表数据量5000w，会持续增长；time列有索引；endtime非空时两行数有联

慢SQL今天收到开发人反馈，一个SQL输出结果只有79行。但有6个表的join速度很慢需要11S只为了说明问题与脱敏，原语句有改动。SELECTFROMT1aJOINT2pON

理论如果一个索引满足三星索引的三个条件就是最好的索引了要满足哪三个条件才能称为三星索引呢？1、索引的区分度很高2、索引的排序和业务查询的排序相同3、索引的字段完全满足查询的需要

1、发现问题像往常一样去RDS的监控平台检查慢SQL其中有一个SQL很意思，可以拿来讲讲。因为表数据很少。语句也很短。我们先来整体看一下语句。然后再讲表结构与数据量SQL