数据库优化

适用场景

1 生产环境数据库CPU持续飙高，通过慢查询日志定位问题SQL并优化

2 开发阶段SQL代码评审，自动识别全表扫描、隐式转换等性能隐患

3 定期巡检数据库，生成索引优化建议报告，预防性能衰退

4 数据库迁移或版本升级前，批量分析存量SQL并给出兼容性改写方案

核心Prompt（安装配置用）

你是一名资深数据库性能优化专家，精通MySQL、PostgreSQL、Oracle等主流数据库的慢查询分析与SQL调优。你的任务是根据用户提供的慢查询日志、表结构DDL和现有索引信息，输出可落地的优化建议。

工作流程：
1. 解析慢查询日志，提取执行时间、扫描行数、返回行数、锁等待等关键指标。
2. 结合表结构分析执行计划，判断是否走索引、是否存在全表扫描、临时表、文件排序等问题。
3. 给出索引优化建议：新增、删除或修改索引，并说明理由和预期收益。
4. 给出SQL改写建议：重写子查询、优化JOIN顺序、消除隐式类型转换、避免SELECT *、合理使用覆盖索引等。
5. 评估优化风险，如索引维护成本、写放大、锁竞争等。

输出格式要求：
- 问题SQL摘要：SQL语句、执行耗时、扫描行数。
- 执行计划分析：关键问题点。
- 索引建议：CREATE/DROP INDEX语句及理由。
- SQL改写：优化后SQL及对比说明。
- 风险提示：可能带来的副作用。

约束条件：
- 只基于用户提供的日志和结构信息分析，不编造不存在的表或索引。
- 建议必须具体可执行，禁止使用“建议优化”等模糊表述。
- 若信息不足，明确列出需要补充的日志或DDL内容。
- 优先推荐低风险、高收益的优化方案。

所需工具 / API对接

需对接：数据库慢查询日志系统（如MySQL slow_query_log、PgBadger）、数据库连接API（执行EXPLAIN）、表结构元数据API（information_schema）、监控告警系统（Prometheus/Grafana）、工单系统（Jira/禅道）用于建议审批。

安装部署步骤

11. 环境准备：确认Agent运行服务器可访问目标数据库，安装Python 3.9+、Docker 20.10+，开放数据库只读账号权限。

22. 安装依赖：执行 pip install sqlalchemy pymysql psycopg2-binary pandas openai 安装数据库驱动与Agent框架依赖。

33. 配置参数：复制 config.yaml 模板，填入数据库连接串、慢查询日志路径、LLM API Key、扫描频率等参数。

44. 导入Prompt：将核心Prompt写入 agent_prompt.txt，通过 python load_prompt.py --file agent_prompt.txt 加载到Agent配置中。

55. 连接工具API：在 config.yaml 中配置数据库只读账号、EXPLAIN执行权限、日志采集接口地址，运行 python test_connection.py 验证连通性。

66. 测试验证：执行 python agent_test.py --sql "SELECT * FROM orders WHERE create_time > '2024-01-01'" 检查输出是否包含执行计划分析与索引建议。

77. 上线部署：使用 docker-compose up -d 启动Agent服务，配置定时任务每天凌晨2点扫描慢查询日志，结果推送至企业微信或邮件。

88. 验证方法：查看日志确认Agent成功解析慢查询并生成建议，人工复核建议准确性，在测试库执行优化SQL验证性能提升。

配置参数

参数名	说明	默认值
`db_type`	数据库类型，支持mysql、postgresql、oracle	mysql
`slow_log_path`	慢查询日志文件路径	/var/log/mysql/slow.log
`scan_interval`	定时扫描间隔，单位小时	24
`llm_model`	使用的LLM模型名称	gpt-4
`max_sql_count`	单次分析最大SQL条数	50
`output_format`	输出格式，支持markdown、json、html	markdown

效果示例

输入：慢查询日志显示 SELECT * FROM orders WHERE user_id = 1001 AND status = 'pending' ORDER BY create_time DESC LIMIT 10; 执行耗时2.3秒，扫描行数120万。表orders有索引(user_id)。

输出：问题SQL执行耗时2.3秒，扫描120万行。执行计划显示使用了user_id索引，但回表后过滤status和排序create_time导致大量随机IO。建议：1. 创建复合索引 idx_user_status_time (user_id, status, create_time)，覆盖查询条件与排序，避免回表和文件排序。2. SQL改写为 SELECT id, user_id, status, amount, create_time FROM orders WHERE user_id = 1001 AND status = 'pending' ORDER BY create_time DESC LIMIT 10; 明确列名，利用覆盖索引。预期性能提升至50ms以内。风险：新增索引会略微增加写入开销，建议在业务低峰期创建。

常见问题

Q1：Agent是否支持非MySQL数据库？
A1：支持MySQL、PostgreSQL、Oracle，通过配置db_type参数切换，需安装对应驱动。

Q2：慢查询日志太大，Agent如何处理？
A2：Agent默认按时间窗口增量读取，可通过max_sql_count限制单次分析条数，建议配合日志轮转使用。

Q3：优化建议可以直接在生产执行吗？
A3：不建议。Agent输出的是建议，需人工复核后在测试库验证，再通过工单系统审批后上线。

Q4：Agent会不会泄露数据库敏感信息？
A4：Agent仅读取慢查询日志和表结构元数据，不读取业务数据。建议使用只读账号并脱敏表名。

Q5：如何评估优化效果？
A5：Agent会给出预期收益，上线后对比优化前后的执行耗时和扫描行数，建议接入监控系统持续观测。

企业落地建议

部署方式：推荐Docker容器化部署，与数据库监控系统同网段，定时任务每日扫描。成本估算：LLM API调用费用约每月200-500元（按每日50条SQL计），服务器资源2核4G即可。注意事项：1. 必须使用只读账号，避免误操作。2. 建议先在测试环境运行两周，积累准确率数据。3. 优化建议需人工审批，不可自动执行DDL。4. 定期更新Prompt以适应业务变化。需要我们帮你落地吗？可以试试免费AI诊断→