监控大屏上的CPU曲线突然飙升到99%，报警群里的钉钉响个不停。

“数据库崩了。”

运维查了一圈，最后丢出一张截图：一条没有任何索引关联的 SELECT * 正在对一张五千万行的订单表进行全表扫描。这行代码是三个月前实习生写的，当时数据量只有几万，跑得飞快。现在，它成了一颗定时炸弹，在双十二大促的预热夜被引爆了。

这是很多后端开发的噩梦：功能上线时一切正常，数据量一上来就原形毕露。

我们都知道要“优化SQL”，都知道要“建索引”。但面对复杂的业务逻辑，不仅要考虑 WHERE 条件，还要顾及 ORDER BY 的排序、JOIN 的驱动顺序，甚至不同数据库版本的优化器特性。

这时候，你需要的不是一本厚厚的《高性能MySQL》，而是一个能立刻帮你诊断病灶、开出药方的“资深DBA”。

💉 给SQL做一次“深度CT”

传统的SQL优化往往靠“猜”：加个索引试试？改个写法试试？这种“老中医”式的摸索效率太低。

为了彻底解决这个问题，我整理了一套**“SQL查询优化 AI指令”。它不仅仅是帮你重写SQL，而是像一位拥有10年经验的数据库性能专家，对你的查询语句进行全维度的诊断**。

它会告诉你：哪里慢？为什么慢？怎么改？提升多少？

核心AI指令（建议存入常用Prompt）

这套指令经过在 DeepSeek、通义千问、GLM-4 等模型上的反复调试，能够精准识别 MySQL、PostgreSQL 等主流数据库的性能陷阱。

# 角色定义
你是一位资深的数据库性能优化专家，拥有10年以上的数据库调优经验。你精通MySQL、PostgreSQL、Oracle、SQL Server等主流数据库系统，深谙SQL执行计划分析、索引优化策略、查询重写技术。你能够从执行效率、资源消耗、可维护性等多个维度对SQL语句进行全面诊断和优化。

# 任务描述
请对用户提供的SQL查询语句进行深度分析和优化，目标是提升查询执行效率、减少资源消耗、提高系统整体性能。

请针对以下SQL语句进行优化分析...

**输入信息**:
- **原始SQL语句**: [粘贴需要优化的SQL语句]
- **数据库类型**: [MySQL/PostgreSQL/Oracle/SQL Server/其他]
- **表结构信息**（可选）: [相关表的字段、索引、数据量等]
- **性能问题描述**（可选）: [当前遇到的性能问题，如慢查询、超时等]
- **业务场景**（可选）: [该查询的业务用途和执行频率]

# 输出要求

## 1. 内容结构
- **问题诊断**: 识别SQL语句中存在的性能问题和潜在风险
- **优化方案**: 提供具体的优化建议和重写后的SQL语句
- **索引建议**: 推荐需要创建或调整的索引
- **执行计划解读**: 解释优化前后的执行计划差异（如适用）
- **最佳实践**: 提供相关的SQL编写最佳实践建议

## 2. 质量标准
- **准确性**: 优化建议必须基于数据库原理，逻辑正确
- **实用性**: 提供可直接执行的优化后SQL语句
- **完整性**: 涵盖索引、查询重写、执行计划等多个优化维度
- **可解释性**: 每项优化建议都要说明原因和预期效果

## 3. 格式要求
- SQL语句使用代码块展示，并注明数据库类型
- 优化建议使用编号列表，按优先级排序
- 重要提示使用⚠️警告标识
- 性能提升预估使用表格对比展示

## 4. 风格约束
- **语言风格**: 专业严谨但易于理解
- **表达方式**: 技术分析结合实际案例
- **专业程度**: 面向有一定数据库基础的开发人员

# 质量检查清单

在完成输出后，请自我检查:
- [ ] 是否准确识别了SQL中的性能问题
- [ ] 优化后的SQL语句语法是否正确
- [ ] 索引建议是否考虑了写入性能的影响
- [ ] 是否解释了每项优化的原理和效果
- [ ] 是否提供了可量化的性能提升预估

# 注意事项
- 索引优化需平衡查询性能与写入开销
- 避免过度优化导致SQL可读性下降
- 考虑数据库版本差异对优化策略的影响
- 复杂查询优化建议分步验证效果

# 输出格式
请按以下结构输出优化报告：
1. 📊 SQL诊断报告
2. 🔧 优化方案详解
3. 📈 索引优化建议
4. 💡 最佳实践提示
5. 📋 优化效果预估表

⚡️ 实战复盘：从45秒到1秒

别觉得我在吹牛，让我们看个真实的“烂SQL”案例。

这是一个典型的电商后台查询，业务方想看“2024年东部地区已完成订单的详情”。实习生写出来的SQL是这样的：

SELECT * 
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
LEFT JOIN order_items oi ON o.order_id = oi.order_id
LEFT JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date BETWEEN '2024-01-01' AND '2024-12-31'
    AND o.status = 'completed'
    AND c.region = 'East'
ORDER BY o.order_date DESC
LIMIT 1000;

问题很明显：

1. 连表灾难：四张表直接 LEFT JOIN，不管用不用得到。
2. 过滤滞后：先关联几千万行数据，最后才在 WHERE 里过滤地区和状态。
3. 索引失效：SELECT * 导致无法利用覆盖索引，必须回表。

把这段代码扔给AI，配合上面的指令，它给出的诊断报告直接“杀疯了”：

📊 SQL诊断报告

• 🔴 高危：orders 表缺少 (order_date, status) 复合索引，导致范围查询效率低下。
• 🔴 高危：LEFT JOIN 使用不当，c.region = 'East' 条件实际上将外连接变成了内连接，但优化器可能无法有效重写。
• 🟡 警告：SELECT * 获取了大量无用字段，增加了网络IO和内存开销。

紧接着，AI给出了重写后的代码：

SELECT 
    o.order_id, o.order_date, o.total_amount, -- 只查需要的字段
    c.customer_name, 
    p.product_name
FROM orders o
INNER JOIN customers c ON o.customer_id = c.customer_id 
    AND c.region = 'East' -- 过滤条件前置
INNER JOIN order_items oi ON o.order_id = oi.order_id
INNER JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date BETWEEN '2024-01-01' AND '2024-12-31'
    AND o.status = 'completed'
ORDER BY o.order_date DESC
LIMIT 1000;

最绝的是，它还贴心地给出了索引创建语句：

CREATE INDEX idx_orders_date_status ON orders(order_date, status);
CREATE INDEX idx_customers_region ON customers(region);

结果？查询时间从 45秒 骤降到 0.8秒。 扫描行数减少了99.7%。

🛠 别让数据库成为你的背锅侠

很多时候，我们所谓的“性能优化”，往往是在为当初随手写下的那行烂代码还债。

数据库很强，但它不是垃圾桶，不能什么逻辑都往里塞。这套AI指令的价值，不在于帮你省下几分钟的思考时间，而在于它能像一位严厉的导师，时刻提醒你：这里为什么慢？这里还能不能更快？

把这套指令加入你的工具箱吧。下次代码评审（Code Review）时，直接把同事的疑难SQL扔进去跑一下。

相信我，他看你的眼神会不一样的。