如何发现慢SQL及高危SQL？
执行时常超过1s的为真实存在的慢SQL，阿里集团内部提供了很多可以方便获取应用慢SQL的方法，例如通过TDDL连接数据库，TDDL会将慢SQL日志统一记录到机器的tddl-slow.log文件中。集团内部的数据库服务中心也会提供相关的慢SQL数据查询记录以及接口。
对于外部用户，可以在数据库配置中启用慢查询日志功能，数据库会将执行时间超过一定阈值的慢SQL语句记录到日志中，也可以方便地获取慢查询日志。或者使用其他的数据库性能监控工具、SQL性能分析工具等。
发现全量SQL
除了执行时长超过1s的慢SQL之外，我们还额外关注了未来可能劣化的慢SQL，这样就需要获取全量SQL，再对其进行分析，筛选出其中风险较大的SQL。我们采取了如下方法：
- 基于JVM Sandbox进行SQL流水记录的采集
关于JVM Sandbox：「JVM-Sandbox提供动态增强你所指定的类，获取你想要的参数和行信息；提供动态可插拔容器，管理基于JVM-Sandbox的模块。」
简单来说，JVM Sandbox可以动态地将你要实现的代码模板打包编织到目标代码中，实现事件的监听、切入与代码增强。将目标代码的Java方法的调用分解为BEFORE、RETURN和THROWS三个环节，由此在三个环节上引申出对应环节的事件探测和流程控制机制。不仅如此，还有Line事件，可以完成代码行的记录。
// BEFORE-EVENT try { /* * do something... */ //LINE-EVENT a(); // RETURN-EVENT return; } catch (Throwable cause) { // THROWS-EVENT }
jvm-sandbox-repeater是JVM-sandbox生态体系下的重要模块，具备了JVM-Sandbox所有特点， 封装请求录制/回放基础协议，也提供了通用可拓展的丰富API。
repeator模块可以无侵入式地录制HTTP/Java/Dubbo入参/返回值，业务系统无感知。基于这个能力，我们可以方便的采集和SQL执行相关的Java方法参数以及返回值。通过配置采集点，来采集执行sql的java代码的相关方法、参数和返回值，辅助实现sql采集功能。
jvm-sandbox-repeater 地址：https://github.com/alibaba/jvm-sandbox-repeater?spm=ata.21736010.0.0.3e5975362i3rJi
- 确认采集点
根据对MyBatis源码分析，我们确认了如下采集点：
JVMSandbox完成数据采集后，通过发送metaq消息的方式，与系统进行对话。对于不同种类的采集消息，我们通过不同的字段加以匹配，最终可以获得每一条SQL流水对应的SQL文本、执行时长、sql参数、db名称、ip端口、sql_mapper资源文件等全部信息，具体如图所示：
以上可以采集到应用的全部SQL，量级是很大的。我们采用了Blink创建时间窗口，进行数据聚合，实时数据处理，减少回流的在线数据量，在此就不展开说明了。
如何识别高危SQL
根据历史慢SQL治理经验，我们把高危SQL分为以下几类：
- 不符合集团SQL规约的SQL，可能会埋坑，造成线上问题，影响执行效率等。
- 通过对SQL语句分析，发现SQL索引使用不当、造成全表扫描，或者SQL扫描行数过多、出现文件排序等。这种SQL即使当前不是慢SQL，随着表数据量的膨胀，未来也可能发展为慢SQL。
- SQL执行时间过长，比较容易理解。对慢SQL来说，执行时间越长，风险越高。
- SQL规约
集团重点强制SQL规约如下：
- 【强制】不要使用count(列名)或count(常量)来替代count(*)，count(*)就是SQL92定义的标准统计行数的语法，跟数据库无关，跟NULL和非NULL无关。
- 【强制】count(distinct col) 计算该列除NULL之外的不重复数量。注意 count(distinct col1, col2) 如果其中一列全为NULL，那么即使另一列有不同的值，也返回为0。
- 【强制】当某一列的值全是NULL时，count(col)的返回结果为0，但sum(col)的返回结果为NULL，因此使用sum()时需注意NPE问题。
- 【强制】使用ISNULL()来判断是否为NULL值。
- 【强制】对于数据库中表记录的查询和变更，只要涉及多个表，都需要在列名前加表的别名（或表名）进行限定。
- 【强制】在代码中写分页查询逻辑时，若count为0应直接返回，避免执行后面的分页语句。
- 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
- 【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
- 【强制】IDB数据订正（特别是删除或修改记录操作）时，要先select，避免出现误删除，确认无误才能提交执行。
我们使用了Druid SQL Parser进行SQL解析，Druid SQL Parser是阿里巴巴的开源项目，可以将SQL语句解析为语法树，可以解析SQL的各个部分，如SELECT语句、FROM语、WHERE语句等，并且可以方便获取SQL语句的结构信息，如表名、列名、操作符等。通过分析SQL，可以轻松判断SQL是否符合规约。
SQL explain语句可以提供关于SQL查询执行的详细信息和执行计划，并且可以了解sql的索引使用情况以及数据访问方式。通过使用Explain语句，可以了解SQL是如何执行的，并且可以看出其可能存在的性能问题。
一个常见的返回结果示例如下：
返回结果解析：
我们重点关注的点如下：
- 使用全表扫描，性能最差，即type=“ALL”
- 扫描行数过多，即rows>阈值
- 查询时使用了排序操作，也比较耗时，即Extra包含”Using filesort”
- 索引类型为index，代表全盘扫描了索引的数据，Extra信息为Using where，代表要搜索的列没有被索引覆盖，需要回表，性能较差。
以上几点都可能造成SQL性能的劣化，是我们需要额外关注的高风险sql。