一、 问题场景被慢 SQL 和索引拖垮的研发与 DBA在大宗商品销采运储系统运行初期DBA 和架构师还能靠人工盯盘。但随着系统膨胀到几千张表、几万个接口噩梦开始了人工救火效率极低月底批量对账慢查询日志动辄几百 MB。DBA 登录服务器、拉取日志、复制 SQL、跑 Explain、找研发沟通改代码处理一条慢 SQL 至少半小时。索引泛滥成灾研发人员换得勤为了赶进度每遇到一个查询就加个单列索引。最后一张核心订单表挂了十几个索引导致写入性能暴跌开单严重卡顿。隐式转换与索引失效频发业务代码里一个小小的WHERE order_no 123把字符串传成数字就能让千万级大表的索引瞬间失效CPU 直接打满。传统的事后排查根本治不了本。企业迫切需要把 DBA 从“看日志的机器”中解放出来。二、 趋势与要求AIOps 是智能运维的必答题随着国务院《关于深入实施“人工智能”行动的意见》及国资委“AI”专项行动的推进AI 与 IT 运维AIOps的融合已经从“可选项”变成了“必答题”。行业数据显示超过 60% 的企业已经在尝试利用大模型辅助 IT 运维。企业的核心诉求非常明确降本增效让 AI 承担 80% 的重复性日志分析工作人工只做最终审核。防患于未然在数据库被彻底打崩之前提前发现索引缺失、死锁隐患。三、 AI 在数据库治理方向的使用在当前的数据持久层AI 可以重点在三个方向发力慢 SQL 智能诊断与改写输入 SQL、表结构和执行计划让 AI 指出为什么慢并给出改写方案。索引智能推荐与冗余清理分析高频查询和从未使用的废索引给出最优的联合索引方案。故障根因辅助排查输入死锁日志和监控指标快速输出故障复盘报告。四、 AI 赋能的核心好处ps: 不能全依赖AI效率提升 10 倍以前排查一条慢 SQL 要 30 分钟现在 AI 3 秒钟给出初步诊断和改写建议。降低人为漏判AI 能不知疲倦地扫描全量慢日志发现隐藏极深的隐式转换或低效 Join。提升系统整体吞吐通过清理冗余索引直接提升核心大表如订单、库存的写入 TPS。五、 工程化落地打通 AI DBA 的“任督二脉”要把 AI 引入数据库治理绝不能搞个对话框就完事。必须打通“采集 → 脱敏 → 拼装 → 推理 → 校验 → 闭环”的完整流水线。一采集定时拉取慢日志不要直接去读庞大的slow.log文件我们在数据库层开启slow_query_log并利用调度服务基础服务层组件定时查询mysql.slow_log系统表。Service Slf4j public class SlowLogCollector { Autowired private JdbcTemplate jdbcTemplate; // 每天凌晨 2 点拉取前一天的 Top 50 慢 SQL Scheduled(cron 0 0 2 * * ?) public void collectSlowLogs() { String sql SELECT sql_text, query_time, lock_time, rows_examined, db FROM mysql.slow_log WHERE start_time DATE_SUB(NOW(), INTERVAL 1 DAY) ORDER BY query_time DESC LIMIT 50; ListSlowLogDTO logs jdbcTemplate.query(sql, (rs, rowNum) - { ... }); logs.forEach(this::processLog); } }二脱敏阻断敏感数据外泄大宗商品的 SQL 里往往带着真实客户名和金额直接发给大模型就是严重的泄露事故。必须进行正则预处理。public class SqlMasker { public static String mask(String sql) { // 1. 屏蔽单引号内的中文字符串如客户名、商品名 // 将 WHERE customer_name 西安XX贸易 替换为 *** sql sql.replaceAll([^]*[\\u4e00-\\u9fa5][^]*, ***); // 2. 屏蔽具体的敏感金额数字 sql sql.replaceAll(\\s*\\d{5,}, ?); return sql; } }三拼装与推理结合元数据调用大模型光给 AI 一句 SQL 是不够的必须附上表结构DDL、当前索引情况以及执行计划ExplainAI 才能精准诊断。Service public class AiDbAnalyzer { Autowired private OpenAiService openAiService; public AiDiagnoseResult analyze(String rawSql) { String maskedSql SqlMasker.mask(rawSql); // 获取 DDL、现有索引、Explain 结果 String ddl metaDataService.getDDL(t_sale_order); String indexes metaDataService.getIndexList(t_sale_order); String explain metaDataService.getExplainResult(rawSql); String prompt buildPrompt(maskedSql, ddl, indexes, explain); // 调用私有化部署的 Qwen2-7B强制返回 JSON 格式 String response openAiService.createChatCompletion(prompt); return JSON.parseObject(extractJson(response), AiDiagnoseResult.class); } private String buildPrompt(String sql, String ddl, String indexes, String explain) { return 你是一个资深的 MySQL 专家。请分析以下慢 SQL。\n 【表结构】\n ddl \n【现有索引】\n indexes \n【执行计划】\n explain \n【SQL语句】\n sql \n 请以 JSON 输出rootCause根因、optimizedSql改写SQL、indexDdl建议添加的索引; } }四校验与闭环防幻觉与工单流转大模型会“胡说八道”比如推荐一个已经存在的索引。AI 的推荐必须经过代码校验并转入工单人工 Review。public void createDbaTicket(AiDiagnoseResult result, String originalSql) { // 防幻觉校验查库确认 AI 推荐的索引是否已存在 if (metaDataService.indexExists(t_sale_order, idx_status_time)) { log.warn(AI 推荐的索引已存在忽略); return; } // 推送工单到钉钉或企微等待人工确认 String ticketContent String.format( 【AI慢SQL诊断】\n根因%s\n原SQL%s\n改写建议%s\n索引建议%s, result.getRootCause(), originalSql, result.getOptimizedSql(), result.getIndexDdl() ); dingTalkClient.sendMarkdown(DBA优化群, ticketContent); }六、 进阶实战用 AI 清理“废索引”除了慢 SQL我们还可以利用 MySQL 自带的sys.schema_unused_indexes系统表找出从未被使用过的废索引。通过定时任务将这份“废索引清单”和业务高频 SQL 发给大模型让 AI 判断哪些可以安全删除哪些可能是日终跑批依赖不能删。AI 会告诉你“idx_customer_name建议直接删除idx_create_time虽然单查没用到但极可能是对账跑批依赖的建议保留。”通过这种机制我们经常能清理掉 20%~30% 的历史遗留冗余索引直接提升核心大表 10% 以上的写入性能。七、 本篇小结把 AI 引入数据库治理核心不在于“模型多聪明”而在于工程链路是否闭环。记住四句话安全第一用私有化模型SQL 必须脱敏AI 绝不直连生产库。数据要全只给 SQL 没用必须带上 DDL、现有索引和 Explain。防幻觉兜底AI 推荐的索引必须经过代码去重校验。流程闭环诊断结果推给研发工单人工审核后执行才是落地的终点。至此【数据持久层】全部完结从底层中间件的高可用到数据持久层的分布式与海量数据治理我们已经把整个大宗商品系统的“操作系统”和“地基”彻底打牢。接下来我们将正式踏入六层架构中篇幅最大、最核心的区域——【业务服务层】。下篇预告业务域全景与 DDD 落地如何避免把微服务写成“分布式单体”
