摘要：本文分享了作者作为十年经验后端开发者，如何利用AI工具（如Cursor）高效处理SQL相关工作的实战经验。文章通过四个典型场景——业务需求翻译为SQL、慢查询优化、复杂统计报表编写、SQL与ORM代码互转——展示了AI在SQL编写中“更快、bug更少”的优势，并提供了具体的操作示例和优化建议，旨在帮助开发者将AI融入日常SQL工作流，提升开发效率。
先交代一下背景
作为一个后端开发，我写了十年 SQL。从大学里最简单的SELECT * FROM users，到后来业务上需要跨 6 张表的关联查询、多层子查询、窗口函数，我自认为 SQL 功底不差。
但我还是被 AI 写 SQL 的能力惊到了。
不是因为 AI 能写 SQL——它当然能写写。但真正让我改观的是：它写的 SQL 比我更快，而且 bug 更少。
就说上周的事。产品经理给我一个需求：统计过去 30 天每个品类下、销量前 10 的商品，还要带上库存信息。
放以前，我得想半天怎么写这个排名加过滤的功能。用窗口函数RANK()？还是用子查询 +LIMIT？怎么写性能才不崩？
这次我直接打开 Cursor，把需求用中文打进去了。AI 三十秒给我方案。我看了一眼，加了一句索引提示，跑了一下，数据对了。全程不到五分钟。
今天把这套「AI 写 SQL」的实战技巧写出来，分四个场景，你遇到哪个直接套用。
场景一：把业务需求翻译成 SQL
这是最日常的场景。产品经理或者运营人员过来说「我要看一个数据」，然后你开始想怎么查。
正确做法：把需求原样告诉 AI，让 AI 帮你写 SQL。
需求：查询过去 7 天每个品类的下单用户数、订单总数、总金额， 按金额降序排列。数据库：MySQL 8.0。表结构如下： orders (id, user_id, category_id, amount, status, created_at) categories (id, name) status 字段取值：0-待支付, 1-已支付, 2-已取消 只统计已支付的订单AI 秒回：
SELECT c.name AS category_name, COUNT(DISTINCT o.user_id) AS user_count, COUNT(o.id) AS order_count, SUM(o.amount) AS total_amount FROM orders o JOIN categories c ON o.category_id = c.id WHERE o.status = 1 AND o.created_at >= CURDATE() - INTERVAL 7 DAY GROUP BY c.id, c.name ORDER BY total_amount DESC;干净、正确、带 GROUP BY 所有非聚合字段（符合 ONLYFULLGROUP_BY）。我自己手写也就这样了。
但 AI 还能做更多——
你可以继续问：
优化一下这个 SQL，订单表数据量大概 500 万条AI 会给优化建议：
建议在 orders 表加联合索引：idx_status_created_at_category (status, created_at, category_id) 可以把统计逻辑改成先过滤再 JOIN，减少 JOIN 数据量： SELECT c.name, ... FROM ( SELECT category_id, COUNT(DISTINCT user_id) AS user_count, COUNT(id) AS order_count, SUM(amount) AS total_amount FROM orders WHERE status = 1 AND created_at >= CURDATE() - INTERVAL 7 DAY GROUP BY category_id ) o JOIN categories c ON o.category_id = c.id ORDER BY total_amount DESC;连索引建议都给你了。你只需要评估一下是否适合你的业务场景，然后执行就行。
场景二：优化慢查询
你线上有一个 SQL 跑了 5 秒，需要优化。以前的做法：EXPLAIN看一下 → 看 extra 字段 → 猜索引怎么加 → 试一次 → EXPLAIN 再看 → 循环。
现在你可以直接贴给 AI：
这条 SQL 在 200 万数据的表上跑了 3.2 秒，帮我优化： SELECT u., o.order_count, o.total_amount FROM users u LEFT JOIN ( SELECT user_id, COUNT() as order_count, SUM(amount) as total_amount FROM orders WHERE created_at >= '2026-06-01' GROUP BY user_id ) o ON u.id = o.user_id WHERE u.status = 1 ORDER BY o.total_amount DESC NULLS LAST LIMIT 20;AI 分析后告诉你：
问题分析： 1. 子查询扫描全表，即使 created_at 有索引也只减少扫描范围 2. ORDER BY total_amount DESC 无法用索引排序，造成 filesort 3. LEFT JOIN 后 LIMIT 20，但子查询还是全量计算 优化方案： 改写为 JOIN + 索引加持： SELECT u., o.order_count, o.total_amount FROM users u JOIN orders o2 ON u.id = o2.user_id JOIN ( SELECT user_id, COUNT() as order_count, SUM(amount) as total_amount FROM orders WHERE created_at >= '2026-06-01' GROUP BY user_id ) o ON u.id = o.user_id WHERE u.status = 1 ORDER BY o.total_amount DESC LIMIT 20; 推荐索引：orders(created_at, user_id, amount)AI 不仅分析了问题，还给出了索引建议和改写方案。你自己来，EXPLAIN 看三次、改两版，没 20 分钟搞不定。
场景三：写复杂统计报表
运营要一个「每个月新增用户数，按渠道分组，再算环比增长」。你想到窗口函数LAG()或者子查询。
直接告诉 AI：
MySQL 8.0。按月统计 2026 年每个渠道的新增用户数，并计算环比增长率。 表结构：users(id, channel, created_at, status) 环比公式：(本月 - 上月) / 上月 * 100% 只统计 status = 1 的用户 按月分组的空月份不需要补零AI 给出：
WITH monthly AS ( SELECT DATE_FORMAT(created_at, '%Y-%m') AS month, channel, COUNT(*) AS new_users FROM users WHERE status = 1 AND created_at >= '2026-01-01' AND created_at < '2027-01-01' GROUP BY month, channel ) SELECT month, channel, new_users, LAG(new_users) OVER (PARTITION BY channel ORDER BY month) AS prev_month, ROUND( (new_users - LAG(new_users) OVER (PARTITION BY channel ORDER BY month)) / LAG(new_users) OVER (PARTITION BY channel ORDER BY month) * 100, 2 ) AS growth_rate FROM monthly ORDER BY channel, month;CTE + 窗口函数，写得比我手敲还顺。环比增长率四舍五入了两位小数，空值处理也到位了——第一个月没有上月数据，prevmonth 自然为 NULL，growthrate 也为 NULL，逻辑上完全正确。
场景四：把 SQL 翻译成 ORM 代码
项目用了 MyBatis Plus，但你写好了原生 SQL。想把它转成 MP 的 LambdaQueryWrapper？
把这个 SQL 转成 MyBatis Plus 的 LambdaQueryWrapper： SELECT id, name, email, created_at FROM users WHERE status = 1 AND created_at >= '2026-06-01' AND (name LIKE CONCAT('%', '张', '%') OR email LIKE CONCAT('%', '张', '%')) ORDER BY created_at DESC LIMIT 20;AI 给出：
LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<User>() .eq(User::getStatus, 1) .ge(User::getCreatedAt, LocalDate.of(2026, 6, 1).atStartOfDay()) .and(w -> w.like(User::getName, "张").or().like(User::getEmail, "张")) .orderByDesc(User::getCreatedAt) .last("LIMIT 20"); List<User> users = userMapper.selectList(wrapper);and()嵌套条件、.last("LIMIT 20")透传、日期处理——全都对。你甚至不需要知道 MyBatis Plus 的这个 API 叫什么。
你也可以反过来：把已有的 ORM 查询转成原生 SQL，方便 DBA 审查。
总结
AI 写 SQL 这件事，已经不只是「能写」的阶段了。它到了比大多数开发写得快、写得好的阶段。
四个场景覆盖了日常 80% 的 SQL 需求：
1.需求翻译→ 把业务需求直接描述，AI 给 SQL（最适合日常）
2.慢查询优化→ 贴 EXPLAIN + SQL，AI 分析问题 + 给索引建议
3.复杂报表→ 窗口函数 + CTE，手写半小时的 AI 三十秒搞定
4.ORM 互转→ SQL ↔ MyBatis Plus/JPA/MPP 一键互转
下次产品经理提数据需求，别自己手写了。把需求描述打给 AI，它在写 SQL 的时候，你还可以再喝口水。
下一篇预告：Spring Boot + 大模型——Java 项目接入 AI 的三种姿势
私信回复「666」，一次性领走：
面试宝典：Java 高频考点速查表、HashMap/ConcurrentHashMap 源码笔记、JVM 调优案例、Spring Boot 面试 50 问
AI 编程工具箱：Cursor/Copilot/Codex 六工具对比表、10 个 Prompt 模板、Debug 万能公式、Cursor 速查手册、AI 图片生成入门、30+ 效率工具包
一份资料包，两个专栏都能用。「唠点键盘之外的」，只讲干货。