有一天开发同学反馈线上业务库中有一条SQL执行很满，每次几乎要跑1分钟才结束，希望我们帮忙优化一下，具体SQL如下：SQL优化第一步 - 查看执行计划对于一个SQL的优化，我们的第一步也是最重要的一步就是查看SQL执行计划，SQL执行计划一方面告诉我们SQL具体的处理行为，另外一方面也可以体现每个执行步骤下大致的资源消耗点。所以我们拿到问题SQL以及对应数据库环境后，登录该环境只读实例进行SQL分析测试。从以上的SQL执行计划我们可以获取到哪些有效信息呢？SQL先对t表扫描查询生产派生表，br

接下来上一篇文章《 SQL优化案例（1）：隐式转换》的介绍，此处内容围绕OR的优化展开。在MySQL中，同样的查询条件，如果变换OR在SQL语句中的位置，那么查询的结果也会有差异，在多个复杂的情况下，可能会带来索引选择不佳的性能隐患，为了避免执行效率大幅度下降的问题，我们可以适当考虑使用统一所有对查询逻辑复杂的SQL进行分离。常见OR使用场景，请阅读以下案例。案例一：不同列使用OR条件查询1.待优化场景SELECT.... FROM`t1` a WHERE a.token= '161496

MySQL是当下最流行的关系型数据库之一，互联网高速发展的今天，MySQL数据库在电商、金融等诸多行业的生产系统中被广泛使用。在实际的开发运维过程中，想必大家也常常会碰到慢SQL的困扰。一条性能不好的SQL，往往会带来过大的性能开销，进而引起整个操作系统资源的过度使用，甚至造成会话堆积，引发线上故障。而在SQL调优的场景中，一类比较常见的问题，就是隐式类型转换。那什么是隐式转换呢？在MySQL中，当操作符与不同类型的操作数一起使用时，会发生类型转换以使操作数兼容，此时则会发生隐式转换。出现隐式转换，往

在一个风和日丽的下午，xxx 突然接到业务方线上业务数据库CPU资源告警信息，立马放下手里的枸杞登录业务方阿里云控制台查看具体问题。对于数据库当前正在发生中的问题，我们首先从数据库实时会话信息中尝试抓取有效信息，可以看到该告警实例的会话已经出现堆积状态，大量会话处于"Sending data"状态且从TIME字段可以看到这些会话长时间执行未结束。会话长时间执行表示当前会话一直占用的数据库资源未释放，且堆积会话基本为同一类型的业务SQL，这也就是导致我们数据库资源打高的问题SQL。我们拎出这个问题