这套 “sql的代码” 的题目乍看很笼统但后台热搜词几乎把日常开发会碰到的 SQL 问题全列出来了去重、窗口函数、慢查询优化、注入攻击、SQL Server 安装、Prisma 调原生 SQL、各种诡异的报错。作为一个常年跟数据库打交道的人我太知道这些点凑在一起意味着什么——就是一套“从入门到生产环境都能跑”的 SQL 知识骨架。这篇内容适合刚接触 SQL 的新手也适合写了几年 SQL 但总在关键时刻卡壳的开发者。我会把常见需求、核心语法、优化思路和踩坑实录放到一起讲尽量让你看完之后自己就能搞定一整套 SQL 代码。1. 先搞清楚这套SQL代码到底在解决什么问题1.1 别把SQL当编程语言它其实是“与数据库对话的翻译官”很多人学 SQL 最大的误区是拿写 Java、Python 的思路来写 SQL。你要真把它当成普通编程语言后面写出来的代码十有八九是灾难。SQL 的全称是 Structured Query Language它本质上是声明式语言你告诉数据库“我要什么数据”而不是“怎么一步步取到数据”。这个思维差别决定了很多问题的答案比如为什么有时候查询很慢为什么同样的逻辑别人写得那么简洁。用生活里的例子打比方SQL 更像是你在餐厅跟服务员点单。你说“来一份番茄炒蛋、米饭”服务员自然会去后厨帮你组合操作。你不需要关心是先切番茄还是先打鸡蛋。但如果你的需求说“把冰箱里所有东西都拿出来挨个看看是不是番茄再决定要不要下锅”那就属于从 SQL 写成了命令式代码又慢又容易出错。所以这套代码的核心永远是围绕“查、增、改、删”四件事展开的SELECT 查数据、INSERT 加数据、UPDATE 改数据、DELETE 删数据。别看热搜词里一堆“sql语句查询”“sql基础”本质上绝大多数人每天面对的就是这四类语句的组合。1.2 一套SQL代码实际要跨过的数据库差异热搜词里同时出现了 MySQL、SQL Server、Oracle、SQLite、PostgreSQL通过 Prisma 间接涉及这也是很多人的真实痛点明明在 MySQL 里能跑的 SQL换到 SQL Server 就报错。原因很简单SQL 有统一的标准但各数据库厂商对标准做了各自的扩展。我举个例子分页查询。MySQL 用的是LIMITSQL Server 用的是OFFSET FETCHOracle 老的写法要靠ROWNUM。再比如字符串拼接MySQL 用CONCATSQL Server 直接可以用。还有空值判断、日期函数、保留字这些细节几乎每个数据库都有自己的脾气。遇到这种情况我的建议是写代码之前先确认运行的数据库类型再决定方言写法。如果项目里用 ORM 框架比如 Prisma、MyBatis尽量别把 SQL 写死在代码里要保留通过配置文件或注解切换 SQL 的空间否则换数据库时候你会把头发揪光。这个点后面讲 Prisma 的时候还会细说。2. 最常用的查询套路这些代码一年能写八百遍2.1 SELECT查询的基本盘新手朋友先把下面这套基本结构吃透它就是 SQL 代码的地基SELECT 字段1, 字段2, ... FROM 表名 WHERE 过滤条件 GROUP BY 分组字段 HAVING 分组后的过滤条件 ORDER BY 排序字段 LIMIT 条数;执行顺序要记清楚它不是按上面写的顺序跑的。数据库实际执行顺序大概是先FROM找到表再WHERE过滤行然后GROUP BY分组接着HAVING过滤分组之后SELECT投影出要的字段最后才ORDER BY排序、LIMIT截断。理解这个顺序最大的好处是你能解释清楚为什么WHERE里不能用别名但ORDER BY里可以。这里有个小坑我必须提写SELECT *特别爽但上了生产环境很危险。你要 5 个字段它把 50 个字段全部查出来不仅网络传输变慢而且会破坏覆盖索引的执行计划。我见过无数次线上事故就是因为SELECT *顺手带出了一个超大的 text 字段直接把内存打满。所以养成习惯列字段名写全。2.2 JOIN连接与多表查询先理清关系再动手多表查询是 SQL 进阶的第一道坎。热搜词里虽然没直接写 JOIN但日常业务里“sql语句查询”大概率就牵扯多张表关联。JOIN 一共有四种常见形式JOIN 类型语义典型场景INNER JOIN只返回两表匹配的行取订单和用户都存在的记录LEFT JOIN返回左表全部行右表无匹配则补 NULL取所有商品及其分类没有分类也要显示商品RIGHT JOIN返回右表全部行左表无匹配则补 NULL和 LEFT JOIN 对称实际用得少FULL OUTER JOIN返回两表全部行不匹配的补 NULL对账场景找出两边不一致的数据写 JOIN 时最需要注意的就是关联字段上要有索引。没有索引的 JOIN 在数据量大时直接变灾难现场。我见过一张 100 万行的表和一张 10 万行的表做连接关联字段没索引跑了十分钟没出结果加了索引之后秒回。这不是夸张是每天都在发生的真实情况。很多新人分不清 JOIN 和 WHERE 过滤的关系。记住一点LEFT JOIN的过滤条件如果写在WHERE里会把你想要的“左表全保留”效果破坏掉。正确做法是把过滤条件写在ON子句里。比如查所有用户及其订单只要已付款的订单-- 错误写法 SELECT u.id, o.order_no FROM users u LEFT JOIN orders o ON u.id o.user_id WHERE o.status paid; -- 正确写法 SELECT u.id, o.order_no FROM users u LEFT JOIN orders o ON u.id o.user_id AND o.status paid;前者会把没有已付款订单的用户行过滤掉相当于从 LEFT JOIN 悄悄变成了 INNER JOIN这个坑我踩过不止一次。2.3 去重的三种写法与取舍“sql语句去重”“清洗---sql语句去重”这些热搜词说明很多人被重复数据折磨过。去重有几种常见方法每种适用场景不一样。第一种是DISTINCT适合最简单的整行去重。它会对查询结果的每一行做整体去重如果两行所有字段都相同就只保留一条。比如查所有不重复的用户城市SELECT DISTINCT city FROM users;第二种是GROUP BY表面上看也能去重但它真正的强项是配合聚合函数。比如统计每个城市有多少用户就必须用 GROUP BYSELECT city, COUNT(*) AS user_cnt FROM users GROUP BY city;第三种是用ROW_NUMBER()窗口函数去重这是清洗数据时最推荐的方案。比如当你面对一张有重复记录的表想保留每个用户最新一条记录WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM user_events ) SELECT * FROM ranked WHERE rn 1;这个写法的核心逻辑是先按 user_id 分组组内按时间倒序编号然后只取编号为 1 的那条。相比 DISTINCT 的死板它给了你掌握“保留哪一条”的控制权。处理历史数据、日志表重复时我基本都用这个套路几乎没有失手过。2.4 分组聚合的代码模板分组聚合是报表类 SQL 最核心的代码。常用的聚合函数有COUNT、SUM、AVG、MAX、MIN。这里有一个大部分教材不会强调的细节聚合前和聚合后的过滤要用不同的关键字。WHERE是在分组前过滤行HAVING是在分组后过滤组。比如你要找出订单总数大于 10、且支付成功的用户SELECT user_id, COUNT(*) AS order_cnt, SUM(amount) AS total_amount FROM orders WHERE status paid GROUP BY user_id HAVING COUNT(*) 10 ORDER BY total_amount DESC;注意WHERE里写的是status paid先把支付成功的行过滤掉再按用户分组。如果你写成HAVING status paid虽然某些数据库也能跑但语义完全错乱性能也不会好因为所有行都会先被拉出来分组。3. 进阶技巧窗口函数、空值与GUID默认值3.1 窗口函数排名和累计的利器sql窗口函数这个热词出现频率极高说明大家普遍需要它又普遍觉得难。窗口函数说白了就是“给每一行开一扇窗让它可以同时看到同组其他行的信息”。它和 GROUP BY 最大的区别是GROUP BY 会把多行合并成一行窗口函数不会它保持原来的行数不变只是额外算出一列。最常用的窗口函数有三类。排名类RANK、DENSE_RANK、ROW_NUMBER。累计类SUM(...) OVER (ORDER BY ...)。移动平均类AVG(...) OVER (ORDER BY ... ROWS BETWEEN ...)。排名类函数看起来差不多实际区别大了。ROW_NUMBER不管有没有并列都会强行排一个连续的号RANK遇到并列会有跳号比如两个第一名之后直接是第三名DENSE_RANK并列不跳号。举个例子分数ROW_NUMBERRANKDENSE_RANK981119821195332如果你想算“每个用户最近一次订单的金额”就可以这样写SELECT user_id, order_no, amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders;然后在外层过滤rn 1拿到每人最近一条订单。这个思路在做同比环比、留存分析、分组 Top N 时几乎是万能模板。我强烈建议把窗口函数当成必学技能它解决问题的能力比传统 GROUP BY 高一个维度。3.2 数字字符串判断与空值处理“db2 sql判断数字字符串函数”这个热词比较冷门但确实挺折腾人。你要判断一个字符串能否转成数字Oracle 的 DB2 里没有直接内置一个IS_NUMBER函数通常需要自己写一个函数或者用REGEXP_LIKE正则判断。类似需求在 SQL Server 里有ISNUMERICMySQL 里可以用CAST(字段 AS SIGNED)配合异常捕获。我更推荐通用的做法正则表达式。判断字段是否全由数字组成-- Oracle / DB2 风格 SELECT * FROM table_a WHERE REGEXP_LIKE(col_a, ^[0-9]$); -- MySQL 风格 SELECT * FROM table_a WHERE col_a REGEXP ^[0-9]$;空值处理也是 SQL 代码里的高频场景。很多人会写WHERE 字段 NULL然后发现查不出来。因为 NULL 在 SQL 里是一个特殊的存在它既不是空字符串也不是 0任何与 NULL 的比较结果都是未知连NULL NULL都返回假。正确写法是IS NULL或者IS NOT NULL。实际业务里更常用的是COALESCE函数它可以接受多个参数返回第一个非 NULL 值SELECT COALESCE(phone, mobile, 无联系方式) AS contact FROM users;如果加个权限校验比如将解析后的URL地址存入数据库或cookie等等我需要小心避开安全边界。让我重新想个例子。嗯邮箱解析。假设config表有email字段。COALESCE场景返回第一个非空值比多个CASE WHEN简洁得多。3.3 GUID默认值主键字段的正确打开方式“sql 默认值guid”这个热词说明很多人碰到了一个具体问题在 SQL Server 里建表时想让主键自动生成 GUID结果不知道怎么写。在 SQL Server 中GUID 对应的类型是uniqueidentifier默认值可以通过NEWID()或NEWSEQUENTIALID()生成。区别在于NEWID()随机生成有极低的碰撞可能但索引碎片比较严重。NEWSEQUENTIALID()顺序生成索引性能更好但只能在列为默认值约束时使用不能直接在 SELECT 里调用。建表模板如下CREATE TABLE users ( id UNIQUEIDENTIFIER DEFAULT NEWID() PRIMARY KEY, name NVARCHAR(50), created_at DATETIME DEFAULT GETDATE() );MySQL 里类似需求用UUID()或者在应用层用 Java 的 UUID 生成。不要想当然地让数据库生成后用自增主键再手动转 GUID虽然能跑但维护起来很别扭。对高并发系统来说自增主键在分布式场景下会有冲突问题GUID 作为业务主键能避免大量依赖这也是为什么很多微服务项目喜欢用 GUID 类主键。4. 慢SQL优化从定位到改写4.1 先确定有没有索引“慢sql优化”“并行sql优化”这两个热词几乎出现在所有开发者的搜索记录里。说实话90% 的慢 SQL 都不是 SQL 本身写得差而是索引没建对。优化一个慢查询第一步永远是看执行计划而不是凭着感觉改 SQL。以 MySQL 为例你可以在 SQL 前面加EXPLAIN查看执行计划EXPLAIN SELECT * FROM orders WHERE user_id 12345 AND created_at 2026-01-01;重点看type这一列。如果出现ALL说明是全表扫描基本上就是慢查询的根源。你要建复合索引user_id, created_at这样两个过滤字段都能命中索引。为什么不能只建单列索引因为两个单列索引在大多数条件下无法高效组合使用数据库通常只能挑一个再用回表方式去另一棵索引树查性能损耗很大。复合索引还有一个很实用的原则叫最左前缀原则。这个我举个例子索引是(user_id, created_at)那查询条件是user_id ?或者user_id ? AND created_at ?都能走索引但只查created_at就完全走不了索引。所以建复合索引时字段的顺序要根据实际查询场景来定把区分度最高的字段放最左边。4.2 慢SQL排查与改写实操排查慢 SQL 要从两个层面入手找出来和改掉它。找出来MySQL 可以看慢查询日志SQL Server 用动态管理视图比如sys.dm_exec_query_stats。修改的时候除了加索引还要改 SQL 写法。最常见的改写套路是避免SELECT *只查需要的字段。因为SELECT *会让优化器无法使用覆盖索引。覆盖索引是指索引本身已经包含了你需要的所有字段数据库可以不回表直接返回结果速度非常快。还有一种是避免在索引字段上做函数运算。比如你把日期字段套了DATE()索引就失效了。优化器查不到原始值的范围只能对全表每一行做函数运算后再比对。例子-- 慢对索引列做了函数处理 SELECT * FROM orders WHERE DATE(created_at) 2026-01-01; -- 快改成范围查询索引能生效 SELECT * FROM orders WHERE created_at 2026-01-01 00:00:00 AND created_at 2026-01-02 00:00:00;再有就是深分页问题。LIMIT 1000000, 20会让数据库把前 100 万行全部扫描出来再扔掉非常浪费。优化思路是用上次查询到的最大 ID 做书签把“偏移”变成“定位”-- 慢 SELECT * FROM orders ORDER BY id LIMIT 1000000, 20; -- 快 SELECT * FROM orders WHERE id 1000000 ORDER BY id LIMIT 20;这种改写不是在所有场景都适用比如列表需要支持任意跳页时就不行但对于翻页型 feed、日志浏览这类场景性能提升是数量级的。4.3 并行SQL优化思路“并行sql优化”一般指数据库执行计划里出现了并行操作或者是你在设计 SQL 时有多个子查询可以并行执行。先说数据库内部的并行。SQL Server、Oracle 都有并行度配置当单条 SQL 扫的数据量很大时优化器可能决定开多个 worker 并行扫描。这时候要注意的不是“并行越多越好”而是并行太高可能把 CPU 打满导致整个实例崩溃。我见过一个生产事故一个统计报表的聚合 SQL 在数据量暴涨后并行度弹到很高直接把数据库服务器的 CPU 吃满其他查询全部超时。后来解决方案有两个方向一是给这条 SQL 加了OPTION (MAXDOP 1)限制并行度不让它抢过多资源二是从业务层面把大查询拆成小时级的小查询提前把结果汇总到中间表。再说外层并行优化。你在应用层写代码时如果多个独立的 SQL 互相之间没有依赖可以用并发执行代替串行执行。比如查用户信息和查用户订单这两条 SQL 互不依赖在 Java 里放进线程池或者 CompletableFuture 并发执行能让你接口响应时间从“两次查询之和”变成“两次查询最慢的那一个”。但注意并发请求数据库会放大数据库压力要控制好并发上限。还有一个容易忽略的点并行优化不要过度。为了拆 SQL 而拆 SQL会把原本一次全表扫描拆成几百次随机查询性能反而更差。SQL 优化的核心原则永远是“减少扫描的数据量”这句话值得贴在显示器上。5. SQL注入与安全防护5.1 注入攻击是怎么发生的“sql注入”“fofa查询sql注入”“sql注入万能密码绕过”这些热搜词说明安全问题永远是热点。SQL 注入的原理其实特别简单你把用户输入的内容直接拼接到 SQL 字符串里用户输入的内容本身也变成了 SQL 代码的一部分。举个例子一个登录功能如果这么写SELECT * FROM users WHERE username 表单项的内容 AND password 表单项的内容;当用户在用户名输入框填admin --、密码随便填拼出来的 SQL 变成了SELECT * FROM users WHERE username admin -- AND password 随便填;在 SQL 里--是注释符它后面所有内容都会被忽略掉。所以这条 SQL 实际只校验了用户名为admin密码条件被注释掉了。攻击者只要猜到一个用户名就能直接登录。这就是“万能密码绕过”的真实原理跟那些神秘的绕过脚本没有本质区别。5.2 万能密码绕过背后的逻辑网上流传的万能密码不只是admin --还有什么 OR 11 --、 OR 11。它们的原理都是用构造条件让 WHERE 恒为真。比如SELECT * FROM users WHERE username OR 11 AND password OR 11;因为11永远成立整条 WHERE 条件结果恒真数据库返回第一行用户多半就是管理员账号。这类攻击不需要多高深的技术只需要理解 SQL 字符串拼接的规则。所以防护手段也极其简单直接我甚至觉得这是整个安全领域投入产出比最高的一项工作。5.3 参数化查询与ORM安全写法防注入的唯一正确姿势就是参数化查询也叫预编译语句。核心思想是SQL 结构里用占位符代替实际值数据库先把 SQL 解析好再把值作为纯参数传进去用户输入永远只是“值”永远不会变成“可执行代码”。以 Java JDBC 为例// 错误字符串拼接 String sql SELECT * FROM users WHERE username username ; // 正确参数化查询 String sql SELECT * FROM users WHERE username ?; PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, username);用 ORM 框架时比如 Prisma也有对应的安全写法。Prisma 里原生查询用$queryRaw它支持参数占位符普通 CRUD 直接用 Prisma Client 生成的方法框架已经帮你做了参数化。切不要因为图省事把用户输入直接拼进$queryRaw。安全底线就一句话永远不要相信用户的输入永远不要用字符串拼接的方式生成 SQL。6. 工具链安装、客户端与ORM原生SQL6.1 SQL Server与SSMS安装要点“sql server安装教程”“sql server 2019安装教程”“sql server 2022安装教程”这类热词扎堆说明一个问题安装 SQL Server 真是个大坑。我装过很多台服务器也帮人远程排过很多次故障大部分问题都出在没理解安装的组件关系上。SQL Server 本身是数据库引擎SSMSSQL Server Management Studio是官方图形化管理工具两者是分开的。热搜词里那个“free download for sql server management studio (ssms) 18.10”指的就是这个工具。安装时不要只装引擎不装工具否则你只能命令行操作新手基本玩不转。安装过程中要注意几个点。第一个实例名选择。默认实例MSSQLSERVER直接用主机名连接就够了命名实例要写成“主机名\实例名”的格式。第二个身份验证模式。尽量选“混合模式”并设置好sa密码否则后续应用连接会抓狂。第三个防火墙放行 1433 端口不然远程连不上。很多安装报错其实是防火墙不是 SQL Server 本身的问题。还有一个常见的诡异报错SQL Server 连不上提示“用户名或密码错误”或“无法连接到 SQL Server”。这种故障的原因可能是密码策略太复杂、实例没启动、或者账号被禁用。排查顺序我总结成了口诀先看服务有没有启动再看端口能不能通最后看账号密码和权限。6.2 通过Prisma执行原生SQLPrisma 是 Node.js 生态里非常流行的 ORM热搜词“prisma 如何调用sql”说明很多人在它里面卡住了。Prisma 默认推荐你用 Prisma Client 生成的方法比如findMany、create这些方法已经帮你做好了类型安全和 SQL 注入防护。但总有些复杂查询不得不写原生 SQL比如带递归、动态透视表、数据库特有函数。Prisma 提供了两个方法$queryRaw和$executeRaw。前者用于查询后者用于更新和删除。官方推荐在$queryRaw里使用标签模板字符串并且用变量而不是拼字符串const results await prisma.$queryRaw SELECT id, email FROM users WHERE id ${userId} ;Prisma 会自动把参数转成预处理语句。但要注意一点$queryRaw返回的数据类型是纯 JS 对象不会自动映射到你 Prisma schema 里的模型类型所以拿到结果后要手动断言类型或者做一层转换。另外$executeRaw返回的是受影响的行数不是结果集别搞混。6.3 命令行导出SQL数据“cmd导出sql”这个热词也很有意思。我猜很多人是想把某个数据库的数据导出成 .sql 文件方便迁移或备份。不同数据库导出的工具和姿势不一样。MySQL 用mysqldump这是最经典的方式mysqldump -u root -p --databases mydb mydb_backup.sql要导出单张表加表名mysqldump -u root -p mydb users users.sqlSQL Server 可以用sqlcmd工具也可以右键数据库任务生成脚本。如果你纯粹想把查询结果导出成 CSVSQL Server 里用bcpbcp SELECT * FROM mydb.dbo.users queryout users.csv -S localhost -U sa -P password -c -t ,命令行导出的好处是可脚本化、可定时执行不像图形界面点来点去容易出错。但要记得把导出的文件放到安全位置避免数据库账号密码和业务数据泄露。7. 高频报错与排查经验7.1 连接类错误实例、端口、防火墙三件套“sql server卸载”“sql server windows nt占用内存”“ora-12518:oracle 监听程序无法分发”这些热词都属于连接类问题。ORA-12518 是 Oracle 监听器无法分发连接常见原因是服务器进程数达到上限比如processes参数太小。处理方法通常是调整 Oracle 参数或者在应用层释放连接池里的空闲连接。SQL Server “windows nt占用内存”这个热词则指向另一种常见担忧SQL Server 确实会尽可能占用内存作为缓存这不一定是坏事但如果一台服务器上既跑数据库又跑其他应用就需要给 SQL Server 设置最大内存上限在服务器属性里面找到“内存”配置把最大服务器内存限制到合理值。连接类问题我建议养成一个固定排查套路。第一确认服务是否运行。Windows 服务管理器里看 SQL Server 服务是不是“正在运行”。第二确认端口能不能通我用telnet 主机名 1433测一下。第三确认连接字符串没有写错实例名本地实例和命名实例的写法差别很大。7.2 语法与数据类型错误这组报错是 SQL 代码最常见的梦魇。sqliteexception(1): while preparing statement, no such column: test_url的意思是 SQLite 在准备 SQL 语句时发现查询的列不存在。解决方法是检查表结构看看是不是表名打错、列名拼错或者忘了执行迁移脚本。这个报错在开发初期出现频率极高几乎每一个用 SQLite 做本地开发的人都会遇到。另一类高频报错是字符串过长比如ora-01704: string literal too long。Oracle 对 SQL 字符串字面量长度有限制很难把超长文本直接塞进 SQL 语句里。正确做法是把大文本放入 CLOB 字段然后用参数绑定而不是直接写在 SQL 里。如果历史 SQL 文件里有超长字符串比如插入大段 HTML 或 JSON也要改用 SQL*Loader 或外部表导入。还有一类容易忽略的报错是字符集。导入 SQL 文件时如果文件本身是 UTF-8但数据库客户端默认字符集不是 UTF-8中文就会乱码或者报错。处理方式是在执行前先设置客户端编码MySQL 里是SET NAMES utf8mb4SQL Server 连接字符串里指定字符编码。7.3 日常排查顺序与生活化理解遇到任何 SQL 报错我的排查顺序始终是一样的先看错误信息本身再定位是连接层、语法层、性能层还是权限层。连接层查网络和配置语法层查字段和表名性能层看索引和执行计划权限层看账号授权。这个顺序看起来简单但能避免你瞎试一堆操作。另外SQL 报错不要怕。你把它想成一段对话数据库告诉你“你刚才那句话我说得不对具体是这个地方不对”。大多数报错信息已经把答案写在里面了很多人只是因为看到英文就慌了直接复制去搜索。搜索是好事但要先尝试读懂那行错误本身你会发现一半问题自己就解决了。比如 “no such column” 就是列不存在你只要去查表结构就行根本不需要搜索。最后分享一个我养成多年的习惯写完 SQL 先跑EXPLAIN看执行计划再决定要不要优化。这句话说起来简单但真的能帮你避免无数线上事故。SQL 代码不是“能跑就行”理解它的执行逻辑你才真正掌握这套代码。