企业官网建设流程全解析

1. 与其背“函数大全”，不如先把需求场景摸清楚

经常会有刚入门的同事问我：“能不能分享一份Oracle数据库常用函数大全？我打算背下来。” 每次听到这种问题我都有点为难。工作这几年，我见过太多人抱着一份函数清单啃了半天，真到了写SQL的时候还是不知道用哪个；反而是一些看起来只掌握了七八个函数的人，写出的语句又稳又快。

秘密不在于背得多，而在于把函数和业务场景挂钩。Oracle的官方文档里函数有几百个，但实际上，我们日常开发、运维、报表抽取、数据清洗中用得上的，翻来覆去也就几十个。剩下的大部分要么是特定场景的专用工具，要么已经被更新的语法替代。所以我一直建议，把“函数大全”重新组织成一张“场景函数表”，按“想对数据做什么”来索引，而不是按字母顺序去背。

这篇文章就是按这个思路整理的。我尽量不写成文档式罗列，而是用实际业务问题带出函数，比如判断字符串里有没有某个字符、怎么取上个月月末、分组后怎么取前三条、怎么避免空值把汇总结果带偏。测试环境都是在HoRain云上开的标准Oracle实例，版本覆盖了11g到19c，函数行为和官方文档没有出入，可以直接在你们自己的库里跑一遍验证。

顺便说一句，我在这里提函数的时候不会刻意区分你是开发者还是DBA，因为在Oracle里这两类人用得最多的是同一批函数，只是使用场景有点差异。开发更关注字符串处理、日期计算、行转列；运维更关注转换函数、空值处理、分析函数在性能监控SQL里的应用。但底层逻辑都是相通的。

2. 字符串处理：这组函数占了日常开发六成用量

字符串处理是Oracle日常开发里出现频率最高的函数类型，没有之一。取子串、找位置、替换内容、去空格、格式化输出，这些都是最基础的需求。我接触过的业务系统里，十个查询SQL至少有六个会用到字符串函数，尤其是做接口对接、日志分析、报表导出的时候。

2.1 SUBSTR 和 INSTR：定位与截断的固定搭档

先说最容易被低估的一对：SUBSTR 和 INSTR。很多人觉得SUBSTR就是“从第几位截到第几位”，INSTR就是“找某个字符在第几位”，单个看都很简单。但它们俩配合使用能解决大量真实问题。

比如说，我们要从一串完整的订单号ORD-2024-12345里取出最后那段纯数字。直接写SUBSTR(ord_no, 5, 4) 只能处理固定格式，一旦长度变了就出错。正确写法是用INSTR找到第三个连字符的位置，再往后截：

SELECT ord_no, SUBSTR(ord_no, INSTR(ord_no, '-', 1, 3) + 1) AS order_seq FROM orders;

INSTR的第三个参数是起始位置，第四个参数是“第几次出现”。这种写法在解析半结构化字段的时候特别管用，比如从URL里取参数、从日志文本里取IP、从商品编号里拆分类码，都是同一个套路。

还有一个高频需求是“判断字符串里是否包含某个内容”。很多人的第一反应是LIKE，比如WHERE name LIKE '%北京%'。其实用INSTR也是常规做法：WHERE INSTR(name, '北京') > 0。这两者的执行计划通常都能走同样的索引路径，但INSTR在动态拼接、参数传入时更灵活，也不会像LIKE那样因为前导百分号导致索引失效的误伤。

SUBSTR还有一个容易踩的细节：Oracle的SUBSTR起始位置是从1开始，但传入0的时候Oracle并不报错，而是自动当作1处理，这和很多编程语言不同。还有个比较冷门的特性是，SUBSTR支持负数起始位，意思是从字符串末尾往前数截取。比如SUBSTR('abcdef', -3)返回def。这在解析固定后缀文件名的场景下非常实用，比先算LENGTH再减位数干净得多。

2.2 REPLACE、TRIM 和 LPAD/RPAD：数据清洗的三件套

ETL和数据清洗场景里，REPLACE、TRIM家族、LPAD/RPAD几乎是天天见面。

REPLACE用来做全局替换，比如把历史数据里的旧部门编码换成新编码：

UPDATE dept_temp SET dept_code = REPLACE(dept_code, 'OLD-', 'NEW-');

如果只是想去掉字符串两边的空格，TRIM就够。但要注意TRIM默认只去掉字符两侧的空格，如果你想去掉的是制表符、换行符，就要写成TRIM(CHAR(9) FROM col)或者用REGEXP_REPLACE。而LTRIM和RTRIM分别是只去掉左边或右边的空格。我在处理从Excel导入的数据时，经常要用TRIM(REPLACE(col, CHR(10), ''))先把换行去掉，再处理前后空格，不然明明看着一样的两个字符串JOIN不上。

LPAD和RPAD是左填充和右填充。典型场景是流水号需要固定长度，比如工单号统一补零到8位：

SELECT LPAD(wo_id, 8, '0') AS wo_no FROM work_orders;

这个函数在银行、财务场景尤其常用，因为对账文件通常要求定长格式。曾经有个旧系统导出的文件里金额字段全部右对齐左补零，我用RPAD处理完之后又发现小数位丢失，这才意识到得用TO_CHAR做格式化而不是自己拼字符串。后面讲转换函数的时候会再展开。

2.3 REGEXP系列：正式处理复杂匹配之前，想清楚代价

当LIKE和INSTR都不够用的时候，就该上正则了。Oracle把正则函数做了不少，常用的有REGEXP_LIKE、REGEXP_REPLACE、REGEXP_SUBSTR、REGEXP_INSTR。

举个例子，校验手机号格式：

SELECT phone, CASE WHEN REGEXP_LIKE(phone, '^1[3-9][0-9]{9}$') THEN 'valid' ELSE 'invalid' END AS check_result FROM member_temp;

再比如把一段文本里的所有数字提取出来：REGEXP_SUBSTR(text, '[0-9]+')，如果有多段数字，还能配合正则表达式里的捕获组，用REGEXP_REPLACE配合反向引用做重排。比如把日期格式从2024/03/15换成2024-03-15：

SELECT REGEXP_REPLACE(dt, '([0-9]{4})/([0-9]{2})/([0-9]{2})', '\1-\2-\3') FROM temp_table;

这里要提个醒：正则函数虽然强大，但在大数据量上跑起来开销不小。正则表达式引擎要做的状态机匹配比普通字符串函数重得多。我在一个几千万行的表上用REGEXP_LIKE做过一次过滤，跑了将近二十分钟，后来改写为“先用INSTR粗筛，再对粗筛结果做正则”，整体时间直接砍到三分钟以内。所以正则适合做精准匹配和复杂抽取，不适合做全表过滤，能前置用LIKE或INSTR挡掉的，就尽量前置。

3. 日期与时间函数：报表、账期、月末结算的命门

日期函数可以说是Oracle里“看起来简单、用起来全是坑”的重灾区。很多报错和结果偏差，都出在对日期函数的行为理解不到位。最常见的两个问题，一个是把日期当字符串比大小，另一个是在日期列上套函数导致索引失效。这两个点后面都会展开。

3.1 SYSDATE、TRUNC 和 ROUND：取哪天、取到哪个精度

SYSDATE返回的是数据库所在操作系统的时间，这一点很多人容易忽略。如果你的应用服务器在北京，数据库服务器在别的时区，用SYSDATE做业务判断就可能出偏差。跨时区场景记得用SYSTIMESTAMP加AT TIME ZONE，或者干脆由应用传入时间。

TRUNC是日期函数里的神器，它可以把日期“砍”到指定的精度。比如：

SELECT TRUNC(SYSDATE) AS today, -- 今天的零点 TRUNC(SYSDATE, 'MM') AS month_start, -- 本月第一天 TRUNC(SYSDATE, 'IW') AS week_start -- 本周周一（按ISO标准） FROM dual;

这个“TRUNC一个日期”的行为经常被新人误以为是字符串截断，其实它是“向下取整到某个时间单位”。金融业务里的账期计算特别依赖它。比如要统计本月每一天的流水，要按天分组，语句可以写成：

SELECT TRUNC(trans_date) AS trans_day, SUM(amount) AS daily_total FROM trans_log WHERE trans_date >= TRUNC(SYSDATE, 'MM') AND trans_date < ADD_MONTHS(TRUNC(SYSDATE, 'MM'), 1) GROUP BY TRUNC(trans_date) ORDER BY trans_day;

这里为什么用>=和<，而不是BETWEEN？因为TRUNC(SYSDATE,'MM') 加上一个月拿到的是下月1号的零点，如果BETWEEN写成<= ADD_MONTHS(TRUNC(SYSDATE,'MM'), 1)恰好就会把下月1号凌晨的数据也包含进去，这是很经典的边界bug。

ROUND在日期上也起作用，ROUND(SYSDATE)会按中午12点这个边界把时间归到当天或次日，ROUND(SYSDATE, 'MM')会按16日这个边界决定归到本月还是下月。做月度汇总时如果你希望“15号下午的数据算作当月”，用ROUND反而有可能导致账期错位，所以我通常只把ROUND用在格式化展示上，核心账期逻辑一律用TRUNC组合。

3.2 ADD_MONTHS、LAST_DAY 和 EXTRACT：账期推移和月度边界

ADD_MONTHS用来做月份推移，比如取上个月的同一天：

SELECT ADD_MONTHS(SYSDATE, -1) FROM dual;

注意ADD_MONTHS有一个比较反直觉的规则：如果原日期是1月31日，加一个月得到的是2月28日或29日，不会自动滚到3月3日。这在计算合同到期日、还款日的时候要特别小心。比如合同约定“每月的最后一天还款”，用ADD_MONTHS(contract_date, 1) 算出的月份日期若落到月末，可能就是错的，更稳妥的是先TRUNC到下月第一天，再减一天，或者直接用LAST_DAY。

LAST_DAY返回指定日期所在月份的最后一天，它和TRUNC搭配几乎能解决所有“月末”问题：

SELECT TRUNC(LAST_DAY(SYSDATE)) AS month_end_start_of_day, -- 本月最后一天零点 LAST_DAY(ADD_MONTHS(SYSDATE, -1)) -- 上个月最后一天 FROM dual;

EXTRACT用来单独抽取日期/时间分量。EXTRACT(YEAR FROM trans_date)、EXTRACT(MONTH FROM sysdate)这类写法在分组统计季度、年份时很直观。但不少Oracle老手更喜欢用TO_CHAR + 格式模型来做，因为EXTRACT不能直接取“周”的概念，而TO_CHAR的格式可以做周数、星期几，功能更全。

还有个常见需求是“判断某一天是星期几”。TO_CHAR(dt, 'd') 返回的是数字，但不同会话的NLS设置可能让1代表周一还是周日产生差异。稳妥的做法是用TO_CHAR(dt, 'DAY', 'NLS_DATE_LANGUAGE=''AMERICAN''')拿英文星期名，再去做业务判断，省得被全球化参数坑。

4. 数值、空值与类型转换：最容易闹出线上事故的角落

字符串和日期是明面上的难点，数值处理和类型转换则是暗处的坑。很多慢查询、ORA错误，问题都出在这一块。

4.1 ROUND、TRUNC、CEIL、FLOOR 和 MOD：别把四舍五入想简单了

数值函数里ROUND的默认行为是四舍五入，TRUNC是直接截断。CEIL和FLOOR分别是向上取整和向下取整。这四个函数在财务计算里要特别留意。

举例：计算含税单价，税率13%，保留两位小数：

SELECT ROUND(unit_price * 1.13, 2) AS round_up, TRUNC(unit_price * 1.13, 2) AS trunc_down FROM product;

如果财务规定“宁可给客户优惠一分，也不能多收”，就要用TRUNC而不是ROUND。这种一分钱差异在批量对账单里可能造成对不平账，我见过因为开发默认用ROUND，结果月末对账差了9分钱，查了半天的案例。

MOD是取余函数，Oracle的MOD对于负数有个特性：结果是a - n * FLOOR(a/n)，比如MOD(-7, 3) 结果是2，和Java/C++等语言的取模行为不一样。这决定了你能不能直接用MOD处理一些轮转分配逻辑。写存储过程或脚本时，如果语言对负数取模行为不同，要特别小心结果漂移。

4.2 NVL、NVL2 和 COALESCE：空值兜底怎么选

空值处理是Oracle里最容易被忽略的“隐藏类型转换器”。NULL参与计算时，结果几乎都是NULL，比如NULL + 1 还是NULL。所以我们在做汇总、拼接时一定要想到空值函数。

NVL(expr1, expr2) 是最常用的：如果expr1为NULL，返回expr2。典型用法是把可能为空的金额默认成0：

SELECT customer_id, NVL(SUM(order_amount), 0) AS total_amount FROM orders WHERE order_date >= TRUNC(SYSDATE, 'MM') GROUP BY customer_id;

NVL2(expr1, expr2, expr3) 的逻辑是分叉的：expr1不为NULL时返回expr2，为NULL时返回expr3。适合“有值和新客标记”这种场景，比如：

SELECT user_id, NVL2(last_login_time, '老客户', '沉睡用户') AS user_status FROM user_profile;

COALESCE比NVL更灵活，可以传多个参数，从左到右取第一个非NULL值：

SELECT COALESCE(phone, mobile, '无联系方式') FROM member;

我推荐在字段可能被多个来源填充的场景里优先用COALESCE而不是嵌套NVL，可读性会好很多。不过有一点要记住：COALESCE的参数类型必须一致，否则Oracle会做隐式类型转换，造成执行计划判断不准甚至拉着索引列做TO_NUMBER。这就引出了下一类函数。

4.3 TO_CHAR、TO_DATE 和 TO_NUMBER：显式转换永远比隐式转换安全

类型转换函数本身不难，难的是什么时候该用、什么时候千万别用。

把数字转成带格式的字符串：TO_CHAR(12345.678, 'FM999G999D00')，其中G是千分位分隔符，D是小数点，FM是去掉前导空格。这种写法在生成报表文件时非常常见。但如果你把一个字符串类型的日期字段转成DATE再比较，比如WHERE TO_DATE(biz_date, 'YYYY-MM-DD') >= TRUNC(SYSDATE)-30，这时候如果biz_date是普通索引列，TO_DATE包上去索引大概率就失效了。更好的做法是维护一个DATE类型的列，或者在查询条件里把右边的日期转成字符串去匹配，比如WHERE biz_date >= TO_CHAR(TRUNC(SYSDATE)-30, 'YYYY-MM-DD')，保证列上不套函数。

隐式类型转换是我们最需要防的东西。Oracle在比对VARCHAR2和DATE、NUMBER时，会悄悄调用转换函数。有时候你用WHERE order_id = '1001'感觉没写转换函数，但Oracle内部可能已经做了TO_NUMBER('1001')。这条SQL如果order_id是字符串类型、且列值里有非数字状况，直接报ORA-01722，甚至可能拖慢整个查询。我的原则是：JOIN条件、WHERE比较条件里，同类型就类型一致，不同类型就显式转换，绝不让Oracle猜。

5. 聚合函数与窗口函数：分组、排名、分页的一次性解决

讲完单行函数，接下来是分析需求里最常用的聚合与窗口函数。这也是“Oracle函数大全”里最有含金量的部分，因为很多业务报表的核心逻辑都靠它们实现。尤其是热词里反复出现的“Oracle分页”，本质上也离不开心函数组合。

5.1 COUNT、SUM、AVG 与 GROUP BY：别只记平均值，还要知道加权

聚合函数不必多说，COUNT、SUM、AVG、MAX、MIN是最基本的。但有几个细节值得提：

• COUNT(*)统计的是行数，COUNT(col)只统计该列非NULL的行数。这是很经典的差异，统计客户数量时用COUNT(customer_id)没问题，但如果customer_id有NULL值，结果会少。
• AVG会自动忽略NULL，如果你想用0参与平均，必须先NVL(col, 0)。
• 在GROUP BY里，能被分组的列并不要求出现在SELECT里，但SELECT里出现的非聚合列必须能被GROUP BY推到，否则语义错误。

重量级的场景是“分组统计后求占比”。比如统计每个产品品类销售额占总销售额的比例：

SELECT category, SUM(sales) AS cat_sales, ROUND(SUM(sales) / SUM(SUM(sales)) OVER (), 4) AS sales_ratio FROM sales_detail WHERE stat_month = '2024-03' GROUP BY category;

这里出现了一个嵌套写法：SUM(SUM(sales)) OVER ()的意思是“先按category分组求和，再在结果集上开一个全量窗口求总和”。很多初学者一看到SUM里面套一个SUM就懵了，实际上这是一种固定套路：组内聚合后的结果，还要再做一次聚合分析。理解了这个，后面窗口函数就顺了。

5.2 ROW_NUMBER、RANK 和 DENSE_RANK：排名到底怎么排

这三个函数非常容易混淆，放在一起看更清楚。

SELECT employee_id, salary, ROW_NUMBER() OVER (ORDER BY salary DESC) AS row_no, RANK() OVER (ORDER BY salary DESC) AS rk, DENSE_RANK() OVER (ORDER BY salary DESC) AS dense_rk FROM employees;

• ROW_NUMBER：即使两个员工工资一样，也会硬分出1、2、3的顺序。
• RANK：相同的工资排名相同，但下一个排名会跳号，比如1、1、3。
• DENSE_RANK：相同的工资排名相同，但不跳号，比如1、1、2。

业务场景里，ROW_NUMBER最常见的用途就是“取每组最新一条”。比如每个客户最近一笔订单：

SELECT * FROM ( SELECT o.*, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC) AS rn FROM orders o ) t WHERE rn = 1;

PARTITION BY负责把数据分成组，ORDER BY决定组内排序。这个写法在去重、取最新状态、漏斗分析里几乎是万能模板。但要注意，如果排序字段有并列，ROW_NUMBER的结果是不确定的，同一SQL跑两次可能得到不同行。遇到这种情况，需要在ORDER BY里加一个业务上的唯一字段（比如订单号）做决胜排序。

5.3 分页查询的两种经典写法：ROWNUM和FETCH FIRST

热词里专门有“oracle分页”，这块必须单独提一下。

11g及以前，Oracle分页的标准写法是三层嵌套ROWNUM，比如每页20条、查第2页：

SELECT * FROM ( SELECT t.*, ROWNUM AS rn FROM ( SELECT * FROM orders ORDER BY order_date DESC ) t WHERE ROWNUM <= 40 ) WHERE rn > 20;

这里的顺序很多人理不清：内层先排序，中间层追加ROWNUM并限制最大行号，外层再过滤起始行号。ROWNUM是在结果集产生过程中逐个编号的，不能直接ROWNUM > 20，因为大于20的行在没编号之前就被丢了。

12c以后有了更简单的FETCH FIRST语法：

SELECT * FROM orders ORDER BY order_date DESC OFFSET 20 ROWS FETCH NEXT 20 ROWS ONLY;

这种写法可读性好很多，但它要全量排序后再做窗口操作，在超大结果集上的性能未必比ROWNUM写法好。生产环境里如果口子特别大，我更倾向用ROW_NUMBER那套方式写成子查询，或者在排序字段上建立索引后配合条件分页。分页优化是另一个大话题，下次有机会单独写一篇。

5.4 LISTAGG：分组内字符串拼接的行转列神器

最后是LISTAGG，Oracle里把一组的多个值拼成一行用起来很方便。比如把每个部门的员工姓名连起来：

SELECT dept_id, LISTAGG(emp_name, '、') WITHIN GROUP (ORDER BY hire_date) AS emp_list FROM employees GROUP BY dept_id;

大家要留意有一个非常容易踩的坑：如果拼接后的字符串总长度超过VARCHAR2限制，11g会直接报ORA-01489，12c以上默认行为也可能截断（实际上还是报错，除非开启兼容相关参数）。所以遇到超长拼接时，可以用PG的STRING_AGG那种思路？不行，Oracle没有。更稳妥的办法是自己写一个PL/SQL聚合函数，或者用XMLAGG绕道。90%的业务场景LISTAGG够用，但做超长文本聚合时要提前想好方案。

6. 函数能解决需求，也能制造故障：几个真实踩坑记录

函数用得越多，踩坑的机会就越大。我挑了四个真实发生过的案例放在这里，它们不是冷门知识，每一项都在生产环境里造成过实际损失。

6.1 LNNVL：三段式条件里藏着“逻辑黑洞”

有一次排查用户查询结果少了数据，业务方坚持条件写的是“要么符合A，要么符合B，要么B为空”，SQL长这样：

SELECT * FROM product WHERE status = 'ACTIVE' OR discount_rate IS NULL OR discount_rate > 0.2;

看着没问题？其实问题出在第一条OR分支和NULL的交互上。如果status='ACTIVE'不成立，且discount_rate为NULL，第三条条件会命中；但如果status为NULL呢？第一条status = 'ACTIVE'的结果是UNKNOWN，不是FALSE，OR会把其他分支再判断一遍，理论上不至于丢。真正的问题是当status不是NULL、只是值不对时，这个条件预计要返回“我这个产品既不是ACTIVE，也没有折扣”，但Oracle的OR逻辑对NULL处理得并不直观。

我后来用LNNVL重构才把查询语义拧清楚。LNNVL的含义是“判断条件是否为UNKNOWN或FALSE”，用于处理“不满足某条件”包括NULL的情况。比如：

WHERE LNNVL(status = 'ACTIVE')

这个函数在日常SQL里用得少，但在做“逻辑取反”时非常有用。举一个真实场景：我们要筛出所有不是VIP且没有备注的用户，但备注可能为NULL：

-- 错误：NULL备注会被漏掉 WHERE is_vip = 'N' AND remark != '加急'; -- 正确 WHERE is_vip = 'N' AND LNNVL(remark = '加急');

很多人会问：为什么不能用remark <> '加急' OR remark IS NULL？那样写当然可以，但可读性和维护性都不如LNNVL干净。这个函数在官方函数清单里非常不起眼，可一旦遇到你就在那里。

6.2 在索引列上套TRUNC：全表扫描的真实代价

日期字段上套TRUNC导致索引失效，可以说是Oracle性能调优的第一大坑。

有一次我接手一个慢查询，每天跑一次月度汇总，耗时从十分钟恶化到两小时。看执行计划：明明主表有几个索引，但全部走FULL TABLE SCAN。排查发现SQL里是这么写的：

WHERE TRUNC(biz_date) = TRUNC(SYSDATE)

biz_date上明明有索引，但TRUNC函数把索引列的值整个改写了，Oracle的普通B树索引是按原始存储值排序的，它没法直接从索引里定位到“TRUNC后的值”等于谁，只能逐行调用函数做判断。

解决方案有两个方向。第一，改查询条件：

WHERE biz_date >= TRUNC(SYSDATE) AND biz_date < TRUNC(SYSDATE) + INTERVAL '1' DAY

这样biz_date原样参与比较，索引可以被有效扫描。第二，如果业务确实动不动就要按天、按月聚合，并且每天做一次TRUNC，更稳的做法是单独建一个函数索引：

CREATE INDEX idx_orders_trunc_bizdate ON orders (TRUNC(biz_date));

函数索引的好处是它在写入时就把TRUNC后的值算好存进索引，查询时可以直接走索引。但代价是每次插入/更新都要维护，并且如果TRUNC的精度变化，索引就要重建，所以只建议针对确切的函数表达式创建。

6.3 隐式转换导致的“万劫不复”：字符串日期和DATE混比

还有个案例是关于“等值条件下隐式转换不走索引”的。开发同学写了一段JOIN：

SELECT * FROM a JOIN b ON a.biz_date = b.biz_date

a.biz_date是DATE，b.biz_date是VARCHAR2。Oracle会优先把VARCHAR2转成DATE去匹配，这在数据量小的时候没感觉，一上了亿级，B表的biz_date列上的索引基本就废了。更危险的是，当VARCHAR2列里混入非日期内容，这条SQL直接报ORA-01843，线上链路当场断掉。

我在做数仓数据同步的时候，遇到这种跨类型JOIN，一律先做清洗转换。要么确定一侧是DATE类型，要么把另一侧显式TO_DATE，绝不让Oracle自己决定。排查这种问题最快的办法是看执行计划的“Predicate Information”段，里面如果出现TO_DATE()、TO_NUMBER()之类的标记，就说明这里有隐式转换。

6.4 LISTAGG超长拼接：ORA-01489的次生灾害

上面的章节提过LISTAGG有长度限制，这里讲一个升级版。我们曾经做一个“分类标签聚合”功能，LISTAGG拼接客户全部兴趣标签，一开始十几个人没事，后来一个高净值客户的标签超过4000个字符，SQL直接报ORA-01489。更麻烦的是这个错误不是稳定复现的，因为标签数量每天都在变，只有到临界点才触发。

后续换成了XMLAGG方案：

SELECT dept_id, RTRIM(XMLAGG(XMLELEMENT(e, emp_name || ',')).EXTRACT('//text()'), ',') AS emp_list FROM employees GROUP BY dept_id;

XMLAGG能处理更大的文本量，但写法非常绕。后来12c以上引入了ON OVERFLOW语法（比如LISTAGG(... ON OVERFLOW TRUNCATE)），又开始方便一些。12c以后我看很多系统的用户还停留在旧版本，所以遇到这个坑不要慌，先确认数据库版本，再决定用XMLAGG还是升级语法。这里只说结论：超长拼接，XMLAGG是通用兜底方案；不断行、不丢数据，但性能比LISTAGG差一点，能不用就不用。

6.5 自测函数行为的简单姿势：dual加样例数据

最后分享一个自测技巧。很多Oracle函数的行为在SQL层面不容易直接观察，我习惯开一个临时SQL窗口，用dual表拼一个样例然后跑：

SELECT TRUNC(SYSDATE, 'IW') AS iso_week_start, TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS now_str, MOD(-7, 3) AS mod_neg, SUBSTR('abcdef', -3) AS sub_neg_start, LISTAGG('测试', ',') WITHIN GROUP (ORDER BY 1) OVER () AS tmp_listagg FROM dual;

写错了也不过是在测试窗口里报个错，不会影响生产。这个习惯帮我避过不少雷，尤其是跨版本升级后函数行为有没有变化。Oracle 19c和11g在很多函数上表现并不完全一样，例如JSON函数、分页语法的支持范围都有差异，线上库版本和本地库版本不一样时，尽量在对应版本环境验证一遍。

还有个顺手的小技巧，函数用久了以后，我会把常用函数记录在一个自己的笔记里，按“业务目标—SQL写法—注意事项”三段式整理。这样比任何网上的函数大全都好用，因为里面记的都是我们自己的业务逻辑和踩坑点。等下次再写月度报表、数据清洗或者接口对接时，翻笔记比翻官方文档快多了。

如果后续有机会，我会再整理一份存储过程里常用的函数封装技巧，把这次聊到的单行函数和分析函数组合进PL/SQL，比如批量数据清洗的自定义函数、报表存储过程里的动态SQL拼接。你们如果已经有类似需求，也可以先在评论区把自己遇到的函数坑写出来，我看哪些最高频，下一篇就优先写哪个方向。