简介：面向Oracle数据库开发者与DBA的官方《SQL Language Reference》19c版参考文档，集中解决日常SQL编写中函数查阅、语法确认与版本差异核对的问题，适合已有一定SQL基础、需要随手查证的中高级使用者。压缩包内仅有1个PDF文件，约14MB，为Oracle原厂英文手册的完整版式，可按语法条目与函数类别逐层检索，数学、字符串、日期时间、转换、加密与聚合等函数均给出定义、参数说明与示例。该文档已有185人学习下载。手册对每类函数的用途、返回值类型与使用限制交代得较为完整，既能作为写SQL时的案头工具书，也便于在调优与迁移场景中比对不同写法；配合清晰的目录结构，可快速定位到具体函数或语句章节，减少试错成本。使用时需留意文档中的版权与许可声明，在合规范围内引用。

1. 从一次报表金额为空说起：Oracle 19c SQL 参考手册不是教程，是函数语义字典

很多人搜oracle函数、oracle函数大全，拿到一份上千页的 19c SQL 语言参考手册后，第一反应是“太厚了，没法看”。我见过更典型的翻车现场：报表里NVL(amount, 0)跑出来是 0，财务口径要求区分“未填”和“填了 0”，开发临时改成COALESCE，结果又碰上隐式转换，金额字段被转成字符串比较，排序和汇总全乱。问题不在函数会不会写，而在函数语义、参数类型、NULL 规则和格式模型有没有对齐。

这份 Oracle 19c SQL 语言参考手册的价值，不是从第一页读到最后一页，而是当成一本“函数语义字典”：写 SQL 前查语法图，写完 SQL 查边界条件，出问题查隐式转换和格式元素。它适合每天写业务 SQL 的开发、做迁移和巡检的 DBA、做数据核对的分析师；不适合零基础拿它当入门教材。下面按“怎么查、怎么落、怎么避坑、怎么回归”拆成可复现的路径。

2. 把函数大全拆成六类索引：字符、数值、日期、转换、聚合、JSON 的检索路径

手册按字母序排函数，工作中却按问题找函数。我的习惯是先建一张自己的函数索引表，把“函数名、类别、返回类型、高风险点、验证 SQL”记下来。后面无论查 19c 手册还是写代码评审，都从这张表进入，比在 PDF 里翻目录快得多。这一章先解决“怎么查”，再解决“怎么验证”。

2.1 先按返回类型和入参建索引，不要按字母表硬背

函数大全最容易出现的误用，是把“名字像”的函数当成“行为一样”。NVL和COALESCE都处理 NULL，但NVL只有两个参数，且第二个参数会按第一个参数类型做隐式转换；COALESCE支持多参数，短路求值，类型推导规则更接近标准 SQL。DECODE和CASE也不是简单替换关系，DECODE在比较时可能触发隐式转换，CASE的可读性和类型控制更稳。

我一般会建一张轻量索引表，字段不追求多，但每条都要能落到一个验证语句：

CREATE TABLE func_index ( func_name VARCHAR2(40) PRIMARY KEY, category VARCHAR2(20), return_type VARCHAR2(30), risk_note VARCHAR2(200), verify_sql VARCHAR2(400) ); INSERT INTO func_index VALUES ('NVL','NULL处理','与第一个参数同类型','第二参数隐式转换，日期场景慎用', 'SELECT NVL(NULL, DATE ''2024-01-01'') FROM dual'); INSERT INTO func_index VALUES ('COALESCE','NULL处理','按参数列表推导','多参数短路，类型需兼容', 'SELECT COALESCE(NULL, NULL, 0) FROM dual'); INSERT INTO func_index VALUES ('JSON_VALUE','JSON','标量','只取标量，对象/数组用 JSON_QUERY', 'SELECT JSON_VALUE(''{"a":1}'', ''$.a'' RETURNING NUMBER) FROM dual'); COMMIT;

这段代码的重点不是建表本身，而是把“函数名”变成“可检索的知识条目”。category用于按问题域过滤，risk_note记录最容易翻车的点，verify_sql保证这条记录不是抄来的，而是能跑的。参数上，func_name建议统一大写，避免nvl和NVL两条重复；risk_note不要写“注意类型”这种空话，要写清楚“哪个参数会转换、转换方向是什么”。

六类索引可以按下面这张表来分。手册里函数远不止六类，但日常业务 SQL 的高频区基本集中在这里：

这张表不是让你背函数，而是让你在遇到“字符串截取不对”“日期差一天”“JSON 取出来是空”时，知道先去手册的哪一节看语法图。索引表建好后，下一步才是读参数。

2.2 用语法图读参数：位置参数、关键字参数和格式模型

手册里每个函数都有一张语法图，很多人跳过图直接看例子，结果参数顺序一换就错。以TO_DATE为例，TO_DATE(char, fmt, nlsparam)里fmt不是可随便省的，省掉后就会依赖会话的NLS_DATE_FORMAT。同一句 SQL 在开发库跑得通、在生产库报ORA-01861，多半就是格式模型没写死。

下面这组语句把“显式格式”和“字面量”放在一起，方便对照：

SELECT TO_DATE('2024-07-01 13:20:30', 'YYYY-MM-DD HH24:MI:SS') AS d1, TO_CHAR(DATE '2024-07-01', 'YYYY-MM-DD') AS s1, CAST('123.45' AS NUMBER) AS n1, TO_NUMBER('1,234.56', '9,999.99') AS n2 FROM dual;

HH24是 24 小时制，MI是分钟，SS是秒；YYYY-MM-DD里的横线是字面量分隔符，不是格式元素。DATE '2024-07-01'是 ANSI 日期字面量，不依赖会话格式，适合做固定日期比较。TO_NUMBER的格式模型里9表示数字位，,和.是位置符，格式模型和输入字符串对不上就会报错。参数说明写进索引表时，我一般只记“哪个参数决定行为”，不抄整段语法图。

读语法图还有一个实际好处：能看出函数是否支持DEFAULT return_value ON CONVERSION ERROR。这个子句在转换函数里很常用，遇到脏数据时可以先返回默认值而不是让整条 SQL 失败。但它不是所有函数都支持，手册语法图里没有就别硬写。

2.3 用最小实验脚本验证函数行为

索引表里的verify_sql不能只写SELECT NVL(NULL,0) FROM dual，那只能证明函数存在，证明不了边界。我一般建一张小实验表，把 NULL、空串、边界日期、超长字符串都塞进去，跑一轮就知道这个函数在当前库里的真实行为。

CREATE TABLE t_func_demo ( id NUMBER, v_str VARCHAR2(20), v_num NUMBER, v_date DATE, v_json VARCHAR2(200) ); INSERT INTO t_func_demo VALUES (1, 'ABC', 10, DATE '2024-01-31', '{"a":1,"b":[2,3]}'); INSERT INTO t_func_demo VALUES (2, NULL, NULL, NULL, '{"a":null}'); INSERT INTO t_func_demo VALUES (3, '', 0, DATE '2024-02-29', '{}'); COMMIT; SELECT id, NVL(v_str, 'NA') AS nvl_str, COALESCE(v_str, v_num::VARCHAR2(20), 'NA') AS coal_str, NULLIF(v_num, 0) AS nullif_num, ADD_MONTHS(v_date, 1) AS next_month, JSON_VALUE(v_json, '$.a' RETURNING NUMBER) AS json_a FROM t_func_demo ORDER BY id;

这段脚本里，id=2和id=3是重点：Oracle 里空串会按 NULL 处理，NVL(v_str,'NA')对这两行都会返回NA，不要把它当成“空字符串保留”。COALESCE里我用了v_num::VARCHAR2(20)，这是显式转换，避免NVL那种按第一参数类型推导带来的意外。ADD_MONTHS对2024-01-31加一个月会落到月末，这是手册里写明的规则，但很多人第一次见会以为算错。

参数怎么改：把v_date换成DATE '2024-02-29'可以验证闰年；把v_json换成{"a":[1,2]}可以看JSON_VALUE返回空还是报错；把v_str换成两个中文字符，可以对比LENGTH和LENGTHB。每改一次，把结果记回func_index.verify_sql，这张索引表才会越长越有用。

3. 常用函数落地：从 NVL、DECODE 到窗口函数的三组可复现 SQL

手册里的函数成千上万，业务 SQL 的高频区其实很集中：NULL 处理、条件表达式、字符串截取、日期加减、聚合和窗口排序。这一章不追求覆盖全部函数，而是把最容易写错、又最常被复制粘贴的三组 SQL 拆开，每组都给可执行代码和参数说明。代码里的表名都是演示表，换成实际表时只需要改字段名。

3.1 NULL 处理与条件表达式：NVL、COALESCE、NULLIF、DECODE、CASE

先看一组对比。假设有一张订单表t_order_demo，discount允许为空，业务要求“空值按 0 参与计算，但统计时要能区分空值和 0”。下面四种写法结果看似一样，语义并不一样：

CREATE TABLE t_order_demo ( order_id NUMBER PRIMARY KEY, customer_id NUMBER, amount NUMBER(10,2), discount NUMBER(10,2), order_date DATE ); INSERT INTO t_order_demo VALUES (1, 101, 100.00, NULL, DATE '2024-07-01'); INSERT INTO t_order_demo VALUES (2, 101, 200.00, 0, DATE '2024-07-02'); INSERT INTO t_order_demo VALUES (3, 102, 300.00, 20, DATE '2024-07-03'); COMMIT; SELECT order_id, NVL(discount, 0) AS nvl_d, COALESCE(discount, 0) AS coal_d, CASE WHEN discount IS NULL THEN 0 ELSE discount END AS case_d, DECODE(discount, NULL, 0, discount) AS decode_d FROM t_order_demo ORDER BY order_id;

NVL(discount,0)和COALESCE(discount,0)在这张表上结果一样，但NVL只有两个参数，第二个参数会向第一个参数的类型靠拢；如果第一个参数是DATE，第二个参数写0就会出问题。CASE最稳，因为IS NULL判断不涉及隐式转换。DECODE(discount, NULL, 0, discount)能匹配 NULL，这是DECODE的特殊规则，但它对数据类型比较宽松，遇到字符串和数字混用时要格外小心。

NULLIF更适合“把某个值当成空”的场景，比如避免除零：

SELECT order_id, amount, NULLIF(discount, 0) AS discount_nonzero, amount / NULLIF(discount, 0) AS ratio FROM t_order_demo ORDER BY order_id;

NULLIF(discount,0)在discount=0时返回 NULL，amount / NULL结果还是 NULL，不会抛ORA-01476。参数上，NULLIF(expr1, expr2)在两者相等时返回 NULL，否则返回expr1；它不改变原表数据，只影响表达式结果。实际写报表时，我一般把CASE放在最外层做口径判断，NVL只用在确定类型一致的简单场景，避免“看起来都是 0，实际类型已经变了”。

3.2 字符串与日期函数：拼接、截取、格式化、时区

字符串函数最容易踩的坑是位置参数。Oracle 的SUBSTR和INSTR都从 1 开始计数，不是 0。下面这组语句把截取、查找、补齐和日期格式化放在一起：

SELECT SUBSTR('ORA-00933', 5, 5) AS err_code, INSTR('A,B,C', ',', 1, 2) AS second_comma, LPAD('7', 3, '0') AS padded, TRIM(' ABC ') AS trimmed, ADD_MONTHS(DATE '2024-01-31', 1) AS next_month, LAST_DAY(DATE '2024-02-10') AS month_end, TO_CHAR(DATE '2024-07-01', 'YYYY-"Q"Q') AS quarter FROM dual;

SUBSTR('ORA-00933',5,5)从第 5 个字符开始取 5 位，得到00933；INSTR('A,B,C',',',1,2)从第 1 个字符开始找第 2 个逗号，返回 4。LPAD('7',3,'0')返回007，第二个参数是总长度，不是补几个字符。ADD_MONTHS对 1 月 31 日加一个月会返回 2 月 29 日（2024 是闰年），这是月末对齐规则，不是简单加 30 天。TO_CHAR里的"Q"是带引号的字面量，Q才是季度格式元素。

日期比较尽量用日期字面量或显式TO_DATE，不要写WHERE order_date = '2024-07-01'。后者依赖会话的NLS_DATE_FORMAT，开发库和生产库设置不同就会翻车。参数上，TO_CHAR(date, fmt, 'NLS_DATE_LANGUAGE=...')可以控制月份名称语言，做多语言报表时要用到；EXTRACT(YEAR FROM date)取年、EXTRACT(MONTH FROM date)取月，比TO_CHAR再转数字更直接。

3.3 聚合与窗口：GROUP BY、LISTAGG、ROW_NUMBER、RATIO_TO_REPORT

聚合函数和窗口函数最容易混。GROUP BY是把多行压成一行，窗口函数是保留明细行再加一列排名或累计值。下面先看聚合：

CREATE TABLE t_emp_demo ( emp_id NUMBER, emp_name VARCHAR2(30), dept_id NUMBER, salary NUMBER, bonus NUMBER ); INSERT INTO t_emp_demo VALUES (1,'A',10,1000,NULL); INSERT INTO t_emp_demo VALUES (2,'B',10,2000,500); INSERT INTO t_emp_demo VALUES (3,'C',10,2000,NULL); INSERT INTO t_emp_demo VALUES (4,'D',20,1500,300); COMMIT; SELECT dept_id, COUNT(*) AS cnt_all, COUNT(bonus) AS cnt_bonus, SUM(salary) AS sum_sal, AVG(salary) AS avg_sal, LISTAGG(emp_name, ',') WITHIN GROUP (ORDER BY emp_name) AS names FROM t_emp_demo GROUP BY dept_id ORDER BY dept_id;

COUNT(*)统计行数，COUNT(bonus)只统计bonus非 NULL 的行，这两个结果在 dept 10 上分别是 3 和 1。AVG(salary)的分母是非 NULL 的salary行数，不是总行数；如果salary有空值，均值会和“总和除以总行数”不同。LISTAGG的WITHIN GROUP (ORDER BY ...)决定拼接顺序，默认分隔符是空串，这里显式写了逗号。19c 里LISTAGG还支持ON OVERFLOW TRUNCATE，拼接结果超过 4000 字节时不会直接报错，但会截断，报表对完整性要求高时不要默认开截断。

窗口函数再看一组：

SELECT emp_id, emp_name, dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn, RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rk, DENSE_RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS drk, LAG(salary) OVER (PARTITION BY dept_id ORDER BY salary) AS prev_sal, RATIO_TO_REPORT(salary) OVER (PARTITION BY dept_id) AS sal_ratio FROM t_emp_demo ORDER BY dept_id, salary DESC;

ROW_NUMBER遇到相同工资会按任意顺序给 1、2、3；RANK会跳号，两个并列第 1 后面直接第 3；DENSE_RANK不跳号，两个并列第 1 后面还是第 2。LAG(salary)取同一部门按工资排序的上一行，第一行返回 NULL。RATIO_TO_REPORT(salary) OVER (PARTITION BY dept_id)算的是当前行工资占部门总工资的比例，分母自动忽略 NULL。参数上，PARTITION BY决定窗口范围，ORDER BY决定窗口内顺序，两者写错不会报错，但结果会悄悄变。

4. 19c 函数边界：JSON 函数族、APPROX_* 与正则匹配的适用面

19c 手册里 JSON 相关函数和近似聚合函数占了不少篇幅，很多人看到名字就直接用，结果在“取数组”“算中位数”“做模糊匹配”上翻车。这一章挑三组边界最明显的函数：JSON 函数族、APPROX_*近似聚合、REGEXP_*正则匹配。每组都给可执行 SQL，重点看“什么时候不该用”。

4.1 JSON 函数族：JSON_VALUE、JSON_QUERY、JSON_TABLE、JSON_MERGEPATCH

JSON_VALUE和JSON_QUERY的分工要记清楚：JSON_VALUE返回标量，JSON_QUERY返回对象或数组。用JSON_VALUE取数组，结果通常是空或者报错。下面这段先取标量，再把数组展开成行：

WITH j AS ( SELECT '{"id":101,"tags":["a","b"],"addr":{"city":"SH"}}' AS doc FROM dual ) SELECT JSON_VALUE(doc, '$.id' RETURNING NUMBER) AS id, JSON_VALUE(doc, '$.addr.city') AS city, JSON_QUERY(doc, '$.tags' WITH WRAPPER) AS tags_json FROM j; WITH j AS ( SELECT '{"id":101,"tags":["a","b"],"addr":{"city":"SH"}}' AS doc FROM dual ) SELECT t.id, t.tag FROM j, JSON_TABLE(j.doc, '$.tags[*]' COLUMNS ( id NUMBER PATH '$.id', tag VARCHAR2(10) PATH '$' )) t;

第一段里，JSON_VALUE(doc,'$.id' RETURNING NUMBER)把 JSON 里的数字转成NUMBER，不加RETURNING默认是字符串。JSON_QUERY(doc,'$.tags' WITH WRAPPER)返回带方括号的数组文本，WITH WRAPPER保证结果是合法 JSON 数组。第二段JSON_TABLE把tags数组展开成多行，COLUMNS里tag PATH '$'表示当前数组元素本身，id PATH '$.id'在数组元素上下文中取不到外层id，所以实际写的时候要么把id放在外层SELECT j里，要么用JSON_TABLE的PATH重新定位。这里保留这个写法是为了提醒：JSON_TABLE的路径上下文很容易写错。

JSON_MERGEPATCH适合做配置合并，但它不是深拷贝工具。下面这个例子把两个 JSON 文档合并：

SELECT JSON_MERGEPATCH( '{"a":1,"b":{"x":1}}', '{"b":{"y":2},"c":3}' ) AS merged FROM dual;

结果里b对象会合并成{"x":1,"y":2}，不是整体替换。参数上，第一个参数是目标文档，第二个是补丁文档；数组按整体替换，不按元素合并。做配置中心或接口字段合并时，这个边界要提前写进注释，否则调用方以为数组也会合并。

4.2 近似聚合函数：APPROX_COUNT_DISTINCT、APPROX_PERCENTILE、APPROX_MEDIAN

APPROX_*系列适合大数据量下的快速估算，不适合精确账务。下面这组语句可以对比精确值和近似值：

SELECT COUNT(DISTINCT customer_id) AS exact_cust, APPROX_COUNT_DISTINCT(customer_id) AS approx_cust, MEDIAN(amount) AS exact_median, APPROX_MEDIAN(amount) AS approx_median, APPROX_PERCENTILE(amount, 0.9) AS approx_p90 FROM t_order_demo;

APPROX_COUNT_DISTINCT返回的是估算值，误差范围和数据分布有关，手册里会给出保证范围；APPROX_MEDIAN和APPROX_PERCENTILE也是近似算法，输入数据量小的时候可能和精确值一样，数据量一大就会出现偏差。参数上，APPROX_PERCENTILE(expr, percentile)的第二个参数是 0 到 1 之间的小数，0.9表示 90 分位。我的用法是：监控大盘、趋势图、抽样分析可以用近似函数；对账、结算、计费一律用精确聚合。把这条写进 SQL 评审清单，比事后解释为什么金额差几毛更省事。

4.3 正则与模式匹配：REGEXP_LIKE、REGEXP_SUBSTR、REGEXP_REPLACE

LIKE能做的事不要上正则。LIKE 'ORA-%'足够表达前缀匹配，REGEXP_LIKE更适合复杂模式，比如“ORA- 加五位数字”：

SELECT REGEXP_LIKE('ORA-00933', '^ORA-[0-9]{5}$') AS is_ora, REGEXP_SUBSTR('ORA-00933', '[0-9]+') AS err_no, REGEXP_REPLACE('A B C', '[[:space:]]+', ' ') AS normalized FROM dual;

REGEXP_LIKE返回布尔值，在WHERE里直接写WHERE REGEXP_LIKE(col, pattern)。REGEXP_SUBSTR只取第一个匹配，要取多个匹配得结合CONNECT BY或REGEXP_COUNT自己拆。REGEXP_REPLACE的第三个参数是替换文本，第四个参数可以指定起始位置和出现次数。正则的代价是 CPU，尤其是大表全表扫描时；能在应用层清洗的脏数据，不要全压给数据库。参数上，模式里的^和$是锚点，[[:space:]]是 POSIX 字符类，写错大小写或转义会直接匹配不到。

5. 避坑与排查：函数手册查得到、SQL 跑不对的五个现场

函数手册能告诉你语法，但告诉不了你“当前会话的 NLS 参数是什么”“这列有没有隐式转换”“空串在 Oracle 里到底算什么”。这一章按“现象 → 原因 → 解决”记录五个现场，都是我在 SQL 评审和排错里反复见到的。每条都尽量给可执行的验证方式，不停留在“注意一下”。

5.1 日期比较差一天：格式模型和会话参数在打架

现象：WHERE order_date = '2024-07-01'在开发库查出 3 条，生产库查出 0 条，或者报ORA-01861: literal does not match format string。原因：字符串被隐式转换成日期，转换格式依赖会话的NLS_DATE_FORMAT；开发库可能是YYYY-MM-DD，生产库可能是DD-MON-RR。解决：比较时用日期字面量DATE '2024-07-01'，或者显式TO_DATE('2024-07-01','YYYY-MM-DD')。排查时先查会话参数：

SELECT parameter, value FROM nls_session_parameters WHERE parameter IN ('NLS_DATE_FORMAT','NLS_DATE_LANGUAGE','NLS_TIMESTAMP_FORMAT');

如果 SQL 里必须传字符串，把格式写死在TO_DATE第二个参数里，不要指望会话设置一致。另一个常见变体是TO_CHAR(order_date,'YYYY-MM-DD') = '2024-07-01'，结果对，但列上套了函数，索引可能用不上；数据量大时改成范围查询order_date >= DATE '2024-07-01' AND order_date < DATE '2024-07-02'。

5.2 NOT IN 查出空结果：NULL 把三值逻辑放大了

现象：WHERE id NOT IN (SELECT id FROM t_order_demo WHERE discount IS NULL)返回 0 行，但子查询明明有值。原因：NOT IN的子查询结果里只要有一个 NULL，整个条件就变成 UNKNOWN，不会返回任何行。解决：子查询里加WHERE id IS NOT NULL，或者改用NOT EXISTS。验证方式：

SELECT COUNT(*) FROM t_order_demo WHERE order_id NOT IN (SELECT customer_id FROM t_order_demo); SELECT COUNT(*) FROM t_order_demo o WHERE NOT EXISTS ( SELECT 1 FROM t_order_demo x WHERE x.customer_id = o.order_id );

第一句在customer_id有 NULL 时可能返回 0，第二句按相关子查询逐行判断，不受 NULL 影响。NOT IN不是不能用，但子查询列必须保证非空；线上 SQL 评审时，我看到NOT IN会先问一句“子查询列有 NOT NULL 约束吗”。

5.3 长度截断：LENGTH 是字符，LENGTHB 是字节

现象：VARCHAR2(10)的字段插入 6 个汉字报ORA-12899: value too large for column。原因：VARCHAR2(10)默认是字节长度，不是字符长度；UTF-8 下一个汉字通常占 3 个字节。解决：建表时明确写VARCHAR2(10 CHAR)，或者按字节估算长度。排查时用LENGTH和LENGTHB对比：

SELECT LENGTH('中文ABC') AS char_len, LENGTHB('中文ABC') AS byte_len FROM dual;

LENGTH返回字符数，LENGTHB返回字节数；SUBSTR按字符截取，SUBSTRB按字节截取。做接口字段校验时，如果对方系统按字节限制，不要只用LENGTH判断。参数上，VARCHAR2(n CHAR)的CHAR是长度语义，建表脚本里写清楚比事后改表更省事。

5.4 排序结果不稳定：NLS_SORT 和 NLS_COMP 在影响比较

现象：同样的ORDER BY name，两个库返回顺序不同，或者WHERE name = 'a'一个库能匹配、另一个库匹配不到。原因：会话或数据库的NLS_SORT、NLS_COMP不同，大小写敏感、重音敏感、排序规则都会变。解决：需要固定排序时用NLSSORT(name,'NLS_SORT=BINARY')，或者在建库/会话层统一参数。排查：

SELECT parameter, value FROM nls_session_parameters WHERE parameter IN ('NLS_SORT','NLS_COMP','NLS_CHARACTERSET');

NLS_COMP=LINGUISTIC时，普通=比较会走语言规则，可能让索引失效；NLSSORT函数也会让普通索引失效，需要函数索引配合。我的习惯是：业务主键、编码类字段用二进制排序；名称类字段如果要求按拼音或语言规则排序，就在查询层显式写NLSSORT，不要依赖默认值。

5.5 函数包住列：索引失效不是玄学，是执行路径变了

现象：WHERE NVL(status,'N') = 'N'或WHERE TO_CHAR(order_date,'YYYY-MM-DD') = '2024-07-01'走了全表扫描，明明有索引。原因：条件左侧是函数表达式，普通 B-Tree 索引存的是列原始值，优化器无法直接用索引定位。解决：改写条件，把函数移到右侧；或者建函数索引。比如：

-- 不推荐：列被函数包住 SELECT * FROM t_order_demo WHERE TO_CHAR(order_date,'YYYY-MM-DD') = '2024-07-01'; -- 推荐：日期范围，能用普通索引 SELECT * FROM t_order_demo WHERE order_date >= DATE '2024-07-01' AND order_date < DATE '2024-07-02'; -- 如果业务必须按 NVL 后的值查，建函数索引 CREATE INDEX idx_order_status_nvl ON t_order_demo(NVL(discount, 0));

函数索引不是后悔药，它会增加写入成本和存储；建之前先确认这个条件是不是高频查询。排查时看执行计划，重点看TABLE ACCESS FULL和INDEX RANGE SCAN的差异，再看filter里有没有函数表达式。SQL 评审时，只要看到WHERE左侧出现函数，就先问一句“能不能改写”。

6. 给函数大全加回归：用例表、失败断言与版本升级检查

手册会更新，数据库会升级，函数语义在边界上可能变。我一般会建一张函数用例表，把“输入、期望输出、失败说明”固定下来，升级前后各跑一遍。表不用复杂，关键字段有case_id、func_name、input_sql、expect_value、owner_note：

CREATE TABLE func_case ( case_id NUMBER PRIMARY KEY, func_name VARCHAR2(40), input_sql VARCHAR2(1000), expect_value VARCHAR2(200), owner_note VARCHAR2(200) ); INSERT INTO func_case VALUES (1,'NVL','SELECT NVL(NULL,0) FROM dual','0','空值替换'); INSERT INTO func_case VALUES (2,'ADD_MONTHS','SELECT TO_CHAR(ADD_MONTHS(DATE ''2024-01-31'',1),''YYYY-MM-DD'') FROM dual','2024-02-29','闰年月末'); INSERT INTO func_case VALUES (3,'JSON_VALUE','SELECT JSON_VALUE(''{"a":1}'',''$.a'' RETURNING NUMBER) FROM dual','1','JSON标量'); COMMIT;

这张表不能自动执行动态 SQL，但可以人工按case_id跑，或者用 PL/SQL 封装一个断言过程。更轻量的做法是给每个函数写一条固定查询，把结果和expect_value对比：

SELECT case_id, func_name, expect_value FROM func_case WHERE case_id IN (1,2,3) ORDER BY case_id;

升级到新补丁或迁移到新库时，先跑这三条，再看结果是否和expect_value一致。不一致就回到手册对应函数的语法图，检查参数类型、格式模型、NLS 设置有没有变化。表格可以按“函数族、用例数、最近一次通过时间”维护，不用追求全量覆盖，先把NVL、TO_DATE、ADD_MONTHS、JSON_VALUE、LISTAGG这些高频函数守住。

从那以后我每次接手一套 19c 库，都会先跑一遍这套函数冒烟用例，再去看执行计划和优化。手册是字典，用例是标尺，两者对上了，函数大全才真正变成可用的工具箱。希望帮到你。

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