企业官网建设流程全解析

简介：面向SQL Server开发人员与数据库管理员的一份函数精析文档，系统梳理了数据库开发中常用且易混淆的各类内置函数。内容包括聚合、日期时间、字符串、数学、转换、元数据、排名等15个函数类别，并逐一说明其用途、参数形式与调用注意事项；同时重点解析确定性函数与非确定性函数的区别，如AVG、CAST、DATEADD属于前者，GETDATE、RAND属于后者，帮助理解函数在视图、存储过程等对象中的使用限制。文档还通过DECLARE、SET、SELECT示例展示了如何将用户变量作为函数输入或捕获函数返回值，并配有SQRT()等具体运算结果，便于直接对照练习。压缩包内含单个doc文档，大小约859KB，结构清晰、内容紧凑，适合作为日常查询与调优时的函数速查手册。已有1190人学习下载，适合希望扎实掌握SQL Server函数用法、提升T-SQL编码效率的数据库从业者。

1. 查 SQL Server 函数大全，难的不是查不到而是不知道用哪个

SQL Server 函数大全这份资料，说穿了就是一份把系统内置函数按类别拆开、逐个讲透的集合手册。我最早拿到它的时候，以为就是纯函数清单，真正用起来才发现，最值钱的部分不在函数列表，而在那些容易被忽略的参数边界和“长得像但用法完全不同”的函数辨析。比如 LEN 和 DATALENGTH 都跟字符长度有关，但一个按字符数算、一个按字节数算，差一个中文字符结果就完全不同。数据清洗、报表口径统一、存储过程调优，这三类场景里函数选型的坑最多。这篇就把我在几个模拟项目里反复踩过的函数用法、参数细节和排查思路写清楚，建议配合官方文档一起看，效果最好。

2. 字符串与日期函数：提取目标文本、格式化日期，先搞清参数口径再写

2.1 字符串提取与裁剪：LEFT、RIGHT、SUBSTRING 与 CHARINDEX 的搭配规则

字符串处理是 SQL Server 日常开发里使用频率最高的一类函数。LEFT 和 RIGHT 语法最简单，LEFT(expression, length) 从字符串左侧截取指定长度，RIGHT 则是从右侧截取。这里最容易混淆的是“字符”和“字节”的概念，SQL Server 默认按字符位置截取，所以处理中文时 LEFT('数据库开发', 3) 的结果是“数据库”而不是三个乱码字节。

SUBSTRING 的定位稍微复杂一点，SUBSTRING(expression, start, length) 的 start 参数从 1 开始计数，不像某些编程语言从 0 开始。我见过有人写 SUBSTRING(name, 0, 2) 想取前两个字符，在 SQL Server 里这个写法不会报错但会少截一个字符，因为 start 为 0 时被当作 1 处理。更隐蔽的是当 start 加上 length 超过字符串总长度时，SQL Server 不会报错，只会截到字符串末尾，所以很多边界计算会悄悄少掉一部分数据还不容易被发现。

CHARINDEX 和 PATINDEX 用来定位子串位置。CHARINDEX('目标', 原文) 返回第一次出现的起始位置，找不到时返回 0。PATINDEX 多了一个模式匹配能力，支持 LIKE 风格的通配符。比如要从一段文本里找到第一个数字的位置，CHARINDEX 做不到，PATINDEX('%[0-9]%', text) 可以直接命中。

片段提取时 CHARINDEX 经常和 LEFT、RIGHT 嵌套使用。一个典型写法是去掉字符串的固定前缀：

-- 截取编号字段中去掉固定前缀后的部分 SELECT product_code, RIGHT(product_code, LEN(product_code) - CHARINDEX('_', product_code)) AS short_code FROM dbo.product_staging;

逻辑说明：CHARINDEX('_', product_code) 定位到第一个下划线出现的位置，LEN(product_code) 获取总字符数，两者相减再传给 RIGHT，得到下划线之后的所有字符。这套写法比先算差值再人工判断更省事，但如果字符串里没有下划线，CHARINDEX 返回 0，RIGHT 会把整个字符串截回来，需要先用 CASE WHEN 做存在性判断，或者配合 NULLIF 兜底。

参数说明：LEN 有两个特性很容易被忽略，一个是不统计末尾空格，另一个是只按字符数计数。LEN('ABC ') 的结果是 3 而不是 4，这在清洗含空格的数据时会产生连带影响。DATALENGTH 则是按字节数计算，VARCHAR 下一英文一字节、一中文两字节，NVARCHAR 下一中一英都占两字节，所以涉及中英文混合的字段，要统一口径后再决定用哪个函数。

2.2 日期时间处理：GETDATE、DATEADD、DATEDIFF 的组合套路

日期函数的坑普遍比字符串函数更深，原因在于 SQL Server 里有多个“当前时间”函数，GETDATE()、SYSDATETIME()、CURRENT_TIMESTAMP 三者返回值精度不同且类型也不同。GETDATE() 返回 DATETIME，精度约 3.33 毫秒，SYSDATETIME() 返回 DATETIME2(7)，精度 100 纳秒。日志表和时间戳字段建议直接用 SYSDATETIME()，而 GETDATE() 只适合对精度无要求的场景。

DATEADD(datepart, number, date) 和 DATEDIFF(datepart, startdate, enddate) 是日期计算的两大基础函数。DATEADD 的 number 可以是负数，用 DATEADD(DAY, -1, GETDATE()) 拿昨天很直观。DATEDIFF 计算的是边界跨越次数，DATEDIFF(MONTH, '2024-01-31', '2024-02-01') 的结果是 1，因为它只看月份参数的跨越，不关心日期是否满一个月。这个特性在计算年龄、工龄时会带来明显偏差。

按月分组的报表里，常用的区间计算是这样：

-- 统计上个月每天的新增订单量 SELECT CAST(order_date AS DATE) AS order_day, COUNT(*) AS order_count FROM dbo.orders WHERE order_date >= DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()) - 1, 0) AND order_date < DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0) GROUP BY CAST(order_date AS DATE) ORDER BY order_day;

逻辑说明：DATEDIFF(MONTH, 0, GETDATE()) 先算出从基准日 1900-01-01 到当前时间跨越了多少个月，这个数字本身就是“本月起点”的索引，再通过 DATEADD 把它转成具体日期。减 1 就是上个月的 1 号 00:00:00，不减就是本月 1 号。区间用左闭右开，避免把本月 1 号的数据漏算或重算。

参数说明：datepart 支持 YEAR、QUARTER、MONTH、DAY、HOUR、MINUTE、SECOND 等常用粒度，还有 WEEK、ISO_WEEK 两种周粒度，每周起始日不同，跨年时周数归属会变化，做周报时一定要确认用的哪一种。

日期格式化上，CONVERT 配合 style 参数的写法比 FORMAT 更稳定。FORMAT(日期, 'yyyy-MM-dd') 虽然直观，但它依赖 .NET CLR 且调用成本高，几万行数据循环格式化就会出现肉眼可见的性能下降。CONVERT(VARCHAR(10), GETDATE(), 23) 就能输出同样的格式，且开销低得多。官方文档里 style 参数有一整张表，日常用 23 对应 yyyy-MM-dd、120 对应 yyyy-MM-dd HH:mm:ss 就足够覆盖百分之八十的报表需求。

3. 聚合与窗口函数：从分组统计到行排名，NULL 与排序规则决定结果对不对

3.1 COUNT、SUM、AVG 对 NULL 的处理差异

聚合函数在 SQL Server 里被使用得最多，但很多人对 NULL 的参与规则没有系统梳理过。COUNT() 统计所有行，不管字段是否为空；COUNT(列) 只统计该列非 NULL 的行。一张 1000 行的订单表，如果备注列有 300 行是 NULL，COUNT(备注) 返回 700，而 COUNT() 返回 1000。

SUM 和 AVG 对 NULL 的规则更直接：NULL 不参与计算，直接跳过。SUM(金额) 遇到 NULL 不会把结果置为 NULL，AVG 的除数是非 NULL 行数，而不是总行数。这里引出一个经典翻车场景：求用户平均消费时，某用户只下过一单且订单金额为 NULL，AVG 结果是 NULL 而不是 0。展示层如果直接用这个值，出现的是空白，不是“未消费”状态，业务口径就错了。

分组去重统计时 COUNT(DISTINCT) 的代价比 COUNT() 高很多，它需要额外的排序或哈希操作。数据量大时，能用 COUNT() 解决问题的不要强行加 DISTINCT。但像统计一个客户在多张订单里出现的唯一城市数这类需求，COUNT(DISTINCT 城市) 又是唯一简洁方案。

-- 按月统计订单数、成交金额与去重客户数 SELECT YEAR(order_date) AS stat_year, MONTH(order_date) AS stat_month, COUNT(*) AS order_cnt, SUM(order_amount) AS total_amount, COUNT(DISTINCT customer_id) AS customer_cnt, AVG(order_amount) AS avg_amount FROM dbo.orders WHERE order_date >= '2024-01-01' GROUP BY YEAR(order_date), MONTH(order_date) ORDER BY stat_year, stat_month;

逻辑说明：GROUP BY 后 SELECT 列表里出现的所有非聚合字段必须包含在 GROUP BY 子句中。这里用 YEAR 和 MONTH 两个函数先把日期归到年、月两个粒度，再统计对应指标。AVG(order_amount) 默认跳过了 NULL 金额，月平均金额会“虚低”还是“虚高”，取决于空白行本身代表 0 还是未录入。

参数说明：SUM 和 AVG 对 BIT 类型字段不适用，BIT 的聚合用 COUNT、MAX、MIN 都可以。SUM 的结果精度有限制，INT 列求和超出 INT 范围会报“将表达式转换为数据类型 int 时发生算术溢出错误”，可以先把列 CAST 成 BIGINT 再聚合。

3.2 ROW_NUMBER、RANK、DENSE_RANK 的排序差异与 LAG/LEAD 的偏移用法

窗口函数解决的是“分组后保留每一条明细”的需求。ROW_NUMBER 给每一行分配连续的递增序号，序号从 1 开始，无论是否有并列。RANK 在并列时会跳过后续编号，比如两行并列第 1，下一行就是第 3。DENSE_RANK 不跳号，两个第 1 之后仍是第 2。

这三个函数在“取每组最新一条记录”场景里的差异表现在并列时。如果同一客户在同一天下了两单，ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC) 会分给其中一单编号 1、另一单编号 2，RANK 则两个都是 1。选错函数会导致同组数据被重复或漏取，最稳妥的做法是先明确业务上是否需要处理并列规则。

LAG 和 LEAD 用于跨行访问。LAG(金额, 1) 取当前行上一行的金额，LEAD 取下一行。缺省参数时超出范围的返回 NULL。环比、同比计算用这两个函数很顺手：

-- 计算本月与上月销售额的环比差值与变化率 WITH monthly_sales AS ( SELECT DATEADD(MONTH, DATEDIFF(MONTH, 0, order_date), 0) AS month_start, SUM(order_amount) AS month_amount FROM dbo.orders WHERE order_date >= '2023-07-01' GROUP BY DATEADD(MONTH, DATEDIFF(MONTH, 0, order_date), 0) ) SELECT month_start, month_amount, LAG(month_amount, 1) OVER (ORDER BY month_start) AS prev_amount, month_amount - LAG(month_amount, 1) OVER (ORDER BY month_start) AS diff_amount, ROUND((month_amount - LAG(month_amount, 1) OVER (ORDER BY month_start)) * 100.0 / LAG(month_amount, 1) OVER (ORDER BY month_start), 2) AS change_rate FROM monthly_sales ORDER BY month_start;

逻辑说明：CTE 先把订单金额按月汇总，外层用 LAG 取上个月金额，做差之后除以基数得到变化率。乘以 100.0 而不是 100，是为了把整数除法转成小数除法，避免结果被截为 0。ROUND 保留两位小数。

参数说明：OVER 子句里的 ORDER BY 决定偏移方向，LAG 和 LEAD 的可选第三个参数是默认值，不写时超出边界的行返回 NULL。用 ISNULL 或 COALESCE 把 NULL 转成 0，能让首月的差值展示为 0 而不是空白，图表更干净。

窗口函数与聚合函数的一个重要边界在于：OVER 里的 ORDER BY 只负责排序，不改变分组边界。PARTITION BY 缺省时，所有行属于同一个窗口，ORDER BY 生效时窗口跨度从起始行到当前行。做累计求和时需要在 OVER 里同时写 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，否则 SQL Server 默认的窗口边界在 ORDER BY 存在时会变成“从起始行到当前行”，不加反而容易踩中不可预期行为。

4. 类型转换与系统函数：隐式转换的隐患，以及三类常见翻车排查

4.1 CAST、CONVERT、TRY_CAST 与 TRY_CONVERT 的选择

数据类型转换是 SQL Server 函数使用中出现问题频率最高的区域之一。CAST 是 ANSI 标准写法，CONVERT 是 SQL Server 扩展写法，两者基本上可以互换，但 CONVERT 多支持 style 参数，日期格式化只能依靠 CONVERT。TRY_CAST 与 TRY_CONVERT 在转换失败时返回 NULL，而不是抛出异常，数据导入阶段做清洗校验时优先用这组。

隐式转换有比显式转换更隐蔽的风险。某列是 NVARCHAR 类型，查询条件里直接写 WHERE order_date = '2024-01-01'，SQL Server 会把字符串转成日期再做比较，这本身没问题。但如果该列没有索引，隐式转换会导致索引失效，因为只有把列本身从 NVARCHAR 转成 DATETIME 才能用上索引，而查询计划的转换是发生在列上的。

转换时的精度丢失也值得留意。FLOAT 转 DECIMAL 可能得到接近但不完全相等的值，DATETIME 转 DATE 会截断时间部分，NVARCHAR 转 VARCHAR 时超过页大小会触发截断。用 TRY_CONVERT 提前升成 NULL 做兜底：

-- 数据清洗阶段：把外部导入的日期文本转为标准日期，无法解析的标记为错误行 SELECT raw_id, raw_date_text, TRY_CONVERT(DATETIME, raw_date_text, 120) AS parsed_date, CASE WHEN TRY_CONVERT(DATETIME, raw_date_text, 120) IS NULL THEN '格式非法' ELSE 'OK' END AS parse_status FROM dbo.external_import_staging;

逻辑说明：TRY_CONVERT 的第三个参数 120 对应 ODBC canonical 格式 yyyy-mm-dd hh:mi:ss(24h)。外部系统导出的文本日期格式五花八门，先指定转换样式能减少歧义。解析失败的整行记录保留在临时表里做人工回查，而不是中断整个导入。

参数说明：SQL Server 的日期 style 参数有完整编号体系，101 对应 mm/dd/yyyy，112 对应 yyyymmdd，126 对应 ISO8601。写死 style 编号的坏处是阅读性差，好处是格式可预期，建议在团队内统一一个常用编号表。

4.2 ISNULL、COALESCE、NULLIF、IIF 的逻辑边界

NULL 处理函数是最容易被误用的。ISNULL 是 SQL Server 专有函数，COALESCE 是标准 SQL 函数，两者都能返回第一个非 NULL 值，但有一个关键差异：ISNULL 强制把返回值转换为第一个参数的类型，COALESCE 则取参与比较的所有表达式中优先级最高的类型。当第一个参数是 VARCHAR(20)，第二个参数是 VARCHAR(50)，ISNULL 的结果会被截断为 20 个字符，COALESCE 不会。不少人在函数大全里看过这个点，但实际出问题时才真正记住。

NULLIF 做的是反向操作，两个参数相等时返回 NULL，不相等时返回第一个参数。它最常见的用途是防除零：NULLIF(除数, 0) 把除数为 0 的算式变成 NULL，配合另一个 ISNULL 就可以输出 0。

IIF 是 SQL Server 2012 引入的简写条件函数，等价于 CASE WHEN 的缩略版。它的求值行为在某些复杂条件下会引入额外计算成本，而且嵌套层数一多可读性极差。能用 CASE WHEN 表达清楚的逻辑不建议用多层 IIF 硬凑。

-- 商品成交率计算：避免除零，保持两位小数精度 SELECT product_id, product_name, view_count, order_count, ROUND( ISNULL( order_count * 100.0 / NULLIF(view_count, 0), 0 ), 2 ) AS conversion_rate FROM dbo.product_daily_stat;

逻辑说明：NULLIF(view_count, 0) 先拦截浏览数为 0 的行，让除法结果变成 NULL，外层 ISNULL 把 NULL 换成 0，最终展示的转化率不会是 NULL。乘以 100.0 保证结果是小数，ROUND 保留两位。

参数说明：COALESCE 的参数列表最多支持 254 个表达式，实际业务中一般用不了这么长。ISNULL 只有两个参数，多参数场景必须改用 COALESCE，这本质上也说明两者在函数大全里归类不同，一个是专用函数，一个是通用标准函数。

4.3 常见问题排查：三个实践中反复出现的故障现象与定位路径

故障一：查询突然变慢，执行计划里出现隐式转换报警。现象是某张千万级订单表的按日查询从毫秒级变到秒级。原因是 where 条件中日期字段写了 CONVERT(VARCHAR(10), order_date, 23) = '2024-06-01'，这会导致 order_date 列上发生隐式转换从而放弃索引。解决方式是改成 order_date >= '2024-06-01' AND order_date < '2024-06-02' 的范围写法，让字段本身参与比较而不是先做函数运算再比较。

故障二：AVG 计算结果和手工核算不一致。现象是统计报表里的平均金额与财务口径差了十几块。原因是订单金额列存在 NULL，AVG 的统计分母不包含 NULL 行，而手工核算把 NULL 当作 0 计入总行数。解决方式是先确认业务规范中 NULL 是否代表 0，如果代表 0，用 AVG(ISNULL(order_amount, 0)) 修正分母口径。

故障三：导入外部数据时日期字段频繁报错。现象是导入了几天后有一批行的日期字段变成 NULL，TRY_CONVERT 没有报错但结果为空。原因是外部数据源里部分日期文本带有中文月份名或者 AM/PM 标记，与 120 格式不匹配，转换失败返回 NULL。解决方式是先对 TEXT 字段做模式统计分析，把不同格式分别识别，再在清洗阶段统一成标准 ISO 格式。

这些故障的特征都是“函数本身没有语法错误，但执行语义与预期不符”。函数大全里大量函数每条都标明了返回类型和边界条件，逐条对照检查通常比断点调试更快。

5. 性能避坑：用内联表值函数替代标量函数，函数调用不再成为查询瓶颈

函数大全里收录的多数函数都能直接使用，但在存储过程或视图里频繁调用标量函数时，性能问题容易被成倍放大。标量函数 UDF 的执行方式是逐行调用，10 万行数据就要进入函数体 10 万次。作个类比，这相当于一次循环里每次迭代都做了一次额外链接，查询优化器对它的重排序能力几乎为零。

更糟的是，在 WHERE 子句里使用标量函数时，该条件基本无法使用索引。即使是简单的 LEFT(字段, 3) = 'ABC'，SQL Server 也很难把它拆成可以命中索引的等价表达式。在模拟项目 X 的报表里我踩过一次这样的坑：订单金额分档用了标量函数 CASE 逻辑，结果本来一秒钟的查询变成了十五秒。

常见做法是把标量函数改写为内联表值函数（Inline Table-Valued Function，ITVF）。内联表值函数的核心是函数体里只有一个 RETURN SELECT 语句，查询优化器可以把它展开到主查询的执行计划中，参与索引选择和连接重排序。

-- 标量函数风格：按金额分档 CREATE FUNCTION dbo.fn_amount_level_scalar ( @amount DECIMAL(12, 2) ) RETURNS VARCHAR(10) AS BEGIN RETURN ( CASE WHEN @amount >= 1000 THEN '高' WHEN @amount >= 100 THEN '中' ELSE '低' END ); END; GO -- 内联表值函数风格：同逻辑改写 CREATE FUNCTION dbo.fn_amount_level_inline ( @amount DECIMAL(12, 2) ) RETURNS TABLE AS RETURN ( SELECT level_desc = CASE WHEN @amount >= 1000 THEN '高' WHEN @amount >= 100 THEN '中' ELSE '低' END ); GO -- 调用对比 SELECT order_id, order_amount, level_desc FROM dbo.orders o CROSS APPLY dbo.fn_amount_level_inline(o.order_amount) f;

逻辑说明：标量函数版本因为逐行调用，主查询无法预估其内部逻辑，执行计划里会出现大量的 Lazy Spool。内联表值函数版本把 CASE 逻辑直接合并进主查询，ORDER 表扫描后追加一个计算列表达式即可，性能差距在千万级数据上非常明显。

参数说明：CROSS APPLY 是调用内联表值函数的标准方式之一。当函数参数来自外层查询的列时，CROSS APPLY 逐行传入参数并返回结果集，逻辑上等同于在 SELECT 列表里嵌套函数，但优化空间完全不同。如果函数没有参数，直接 JOIN 到 FROM 子句即可，不需要 APPLY。

从那以后，我每次在 SQL Server 里新建函数都会先问自己一句：这个功能能不能用一条 SELECT 表达？如果返回逻辑可以用单个查完成，就写成内联，绝不写成标量。实践下来，报表类查询的响应时间普遍降了一到两个数量级。函数大全教人认识函数，但这套“改写思路”才算真正把函数用到位，希望帮到你。

本文还有配套的精品资源，点击获取