背景:

事故频发

•在工作过程中每年都会看到 SQL 问题引发的线上问题，一条有问题的 SQL 足以拖垮整个数据库

不易发觉

•对于 SQL 性能问题测试在预发环境不易发现（数据量小）

•SAAS 系统隔离字段在 SQL 条件中遗漏，造成越权风险

•业务初期 SQL 没问题，业务增长容易出现事故

•DBS 慢 SQL 不支持实时报警，无法及时发现

•靠大家 review 代码总会出现遗漏

事后处理

•每次都是线上接口性能、数据库报警才意识到问题，再去优化 SQL，此刻有可能引发线上的严重事故；

思考：

虽然我们上线前会做代码 review,但是单纯通过人为去发现总是有遗漏；

而且我们更希望问题在测试和预发环境提前暴漏出来，尽量避免带到线上；

是否可以通过技术手段提前发现问题？

是否可以把人为发现变成自动预警？研发新工具来自动检测有问题的 SQL！

问题：

我们可以通过拦截器进行拦截，并执行 explain 分析等操作，在高并发的情况下，我们如何减少对现有系统和数据库的影响？？

对于相同的 SQL 重复请求我们是否可以做缓存进行拦截，避免重复解析？

既然找到有问题的 SQL，我们是否可以结合大模型给出用户一个合理的优化建议？

综上所述，我们根据这些思考和遇到的问题设计一个可以事前进行 SQL 巡检的插件。

流程设计：

行动：

通过开发 SQL 巡检检插件查实现问题 SQL 自动预警

1.利用 SQL 拦截器，拦截系统执行的 SQL

2.开启异步线程池，不阻碍业务流程的执行，解析 SQL，忽略具体入参数据和格式，MD5 加密 SQL 语句，为了防止重复 SQL 执行，将之前拦截过的 MD5 值缓存，可以自定义缓存时间，这段时间内容不会解析相同的 SQL

3.为了保障业务系统的稳定性，接入插件的时候支持手动数据源的注入，可以选择主或者从，来执行后续的 explain/show create table 操作

4.通过 explain/show create table 执行的结果，以及 SQL 语句通过 http/MQ 发送给 SQL 巡检平台

5.SQL 巡检平台接受信息进行内容拆分，获取表名和条件；

6.首先通过执行计划分析:如：[possible_keys][key]分析索引是否使用，如未使用会及时预警通知,并记录到巡检平台；

7.其次进行表和查询条件分析，通过读取平台的配置，设置某一个表的查询条件的校验规则（支持正则表达），如:xxx_info 表条件必须使用 xxx_code,如不符合规则也会及时预警通知，并记录到巡检平台；

SQL风险预警

【描 述】SQL安全检测-table_name(表名)不符合条件规则:.*org_no.* (正则表达式) 【traceId】wewrerew234234242342 (请求ID) 【执行方法】com.XXX.XXX.XX.FINDBYID(mapper方法) 【SQL内容】select * from table_name where xxx=1 and yyy=2 【系统名称】所属系统

SQL风险预警

【描 述】SQL索引检测-table_name(表名)未使用索引; 【traceId】aa6ac6c89bec4f7dfdfdf74719ae583(请求 ID)【执行方法】XXXXXMapper.selectResult(mapper 方法) 【SQL内容】select * from table_name where xxx=1 and yyy=2【系统名称】所属系统

1.巡检平台提供了一些报警阈值管理、校验规则管理等，来满足不同系统的不同表的不同要求

2.巡检平台同时会把有问题的 SQL 进行展示，支持一键分析，因为之前咱们已经获取到执行计划结果和建表语句，把这些信息交给 chatgpt，通过大模型分析，并返回响应的建议，辅助用户进行治理

总结：

插件接入成本低，能快速接入，不影响现有业务和流程；

通过自定义校验规则保障 SQL 的安全性，清除安全隐患；

通过自动巡检插件，我们能提前在测试预发环境自动发现 SQL 存在的问题；

通过精准报警，可以追踪到具体的功能请求链路，快递定位；

通过平台让大模型生成优化建议，指导我们快速优化 SQL;