一、前言 上一篇我们说了 腾讯一面：说一说 MySQL 中索引的底层原理，相信你对索引有个很清晰的认识了，这一篇我们来说一说慢 SQL 的排查以及调优。为啥面试官要问这个问题，其实跟上一篇的索引底层原

博主（编码砖家）负责的项目主要采用阿里云数据库MySQL，最近频繁出现慢SQL告警，执行时间最长的竟然高达5分钟。导出日志后分析，主要原因竟然是没有命中索引和没有分页处理 。 其实这是非常低级的错误，

1. 对于 mysql，不推荐使用子查询和 join 是因为本身 join 的效率就是硬伤，一旦数据量很大效率就很难保证，强烈推荐分别根据索引 单表取数据，然后在程序里面做 join，merge 数据。 2. 子查询就更别用了，效率太差，执行子查询时，MYSQL 需要创建临时表…

一个完整的SQL语句中会被拆分成多个子句，子句的执行过程中会产生虚拟表(vt)，但是结果只返回最后一张虚拟表。从这个思路出发，我们试着理解一下JOIN查询的执行过程并解答一些常见的问题。 如果之前对不同JOIN的执行结果没有概念，可以结合这篇文章： https://www.co…

“  这篇文章主要为了说明规矩要遵守，但是也别这么死板，要知道因场景不同而变化。了解各自的优缺点，在不同业务中根据需求选择使用。 ”

前言 最近在做项目涉及到Mysql的复杂日期查询，日期查询其实在数据库中查询其实还是用的挺多的，比如查询开始日期到结束日期的区间信息，查询日期小于有效日期的信息，查询当天的日期，明天的日期，做比较等。

背景大家在日常工作中，往往需要对数据库的表结构做变更，一般涉及到增删字段，修改字段属性等ALTER的操作。然而，在大表场景下，特别是千万级、亿级的大表，如果处理不当。这些操作往往会引发锁表的巨大隐患，

MySQL 5.7 背景需求 生产环境加字段是一个非常常见的操作。 但是现在的场景是，单表有大约1亿行数据，磁盘占用500G，1秒中内会有大量的select delete操作，且耗时敏感，所以先调研一

这天我正在午休呢，公司DBA就把我喊醒了，说某库出现大量慢SQL，很快啊，很快，我还没反应过来，库就挂了，我心想现在的用户不讲武德啊，怎么在我睡觉的时候大量请求呢。 这是很常见的一个场景哈，因为很多业务开始数据量级不大，所以写sql的时候就没注意性能，等量级上去，很多业务就需要…