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-15SELECT 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_LANGUAGEAMERICAN)拿英文星期名再去做业务判断省得被全球化参数坑。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。典型用法是把可能为空的金额默认成0SELECT 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分组内字符串拼接的行转列神器最后是LISTAGGOracle里把一组的多个值拼成一行用起来很方便。比如把每个部门的员工姓名连起来SELECT dept_id, LISTAGG(emp_name, 、) WITHIN GROUP (ORDER BY hire_date) AS emp_list FROM employees GROUP BY dept_id;大家要留意有一个非常容易踩的坑如果拼接后的字符串总长度超过VARCHAR2限制11g会直接报ORA-0148912c以上默认行为也可能截断实际上还是报错除非开启兼容相关参数。所以遇到超长拼接时可以用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的交互上。如果statusACTIVE不成立且discount_rate为NULL第三条条件会命中但如果status为NULL呢第一条status ACTIVE的结果是UNKNOWN不是FALSEOR会把其他分支再判断一遍理论上不至于丢。真正的问题是当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混比还有个案例是关于“等值条件下隐式转换不走索引”的。开发同学写了一段JOINSELECT * FROM a JOIN b ON a.biz_date b.biz_datea.biz_date是DATEb.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拼接。你们如果已经有类似需求也可以先在评论区把自己遇到的函数坑写出来我看哪些最高频下一篇就优先写哪个方向。