摘要本文分享了作者作为十年经验后端开发者如何利用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()或者子查询。直接告诉 AIMySQL 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 自然为 NULLgrowthrate 也为 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 给出LambdaQueryWrapperUser wrapper new LambdaQueryWrapperUser() .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); ListUser users userMapper.selectList(wrapper);and()嵌套条件、.last(LIMIT 20)透传、日期处理——全都对。你甚至不需要知道 MyBatis Plus 的这个 API 叫什么。你也可以反过来把已有的 ORM 查询转成原生 SQL方便 DBA 审查。总结AI 写 SQL 这件事已经不只是「能写」的阶段了。它到了比大多数开发写得快、写得好的阶段。四个场景覆盖了日常 80% 的 SQL 需求1.需求翻译→ 把业务需求直接描述AI 给 SQL最适合日常2.慢查询优化→ 贴 EXPLAIN SQLAI 分析问题 给索引建议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 效率工具包一份资料包两个专栏都能用。「唠点键盘之外的」只讲干货。