本文主要是介绍SQL事前巡检插件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
背景:
事故频发
•在工作过程中每年都会看到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;
这篇关于SQL事前巡检插件的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
