本文针对 oracle 中带时间戳排序与条件过滤的单行查询，提供索引策略、执行计划分析及多种优化写法（包括 row_number 和 rownum 方案），帮助在保证结果正确性的同时显著提升查询性能。
在 Oracle 中，类似 SELECT ... WHERE a = ? AND b = ? AND SYSTIMESTAMP <= d_timestamp ORDER BY d_timestamp DESC FETCH FIRST 1 ROWS ONLY 的查询看似简洁，但其性能高度依赖执行计划与索引设计。尽管你已在 C_NUMBER、CA_NUMBER 和 D_TIMESTAMP 上分别创建了单列索引，但这并不足以支撑高效执行——因为 Oracle 无法有效合并多个单列索引完成复合过滤 + 范围扫描 + 排序的联合操作。
✅ 首要建议：创建组合索引
为覆盖 WHERE 条件与 ORDER BY，推荐建立以下前导列顺序的复合索引：
CREATE INDEX idx_tm_cam_opt ON TM_CAM (C_NUMBER, CA_NUMBER, D_TIMESTAMP);
理由：C_NUMBER 和 CA_NUMBER 是等值过滤（高选择性），应置于索引前列；D_TIMESTAMP 作为范围条件（SYSTIMESTAMP <= D_TIMESTAMP）和排序依据，放在末位可支持索引范围扫描（Index Range Scan）并天然满足 ORDER BY ... DESC，使 FETCH FIRST 1 ROWS ONLY 能在找到首个匹配项后立即终止，避免全排序。
? 务必验证执行计划
在应用优化前，始终运行：
EXPLAIN PLAN FOR SELECT NAM, RSON, URL FROM TM_CAM WHERE C_NUMBER = :A_C_NUMBER AND CA_NUMBER = :A_CA_NUMBER AND SYSTIMESTAMP <= D_TIMESTAMP ORDER BY D_TIMESTAMP DESC FETCH FIRST 1 ROWS ONLY; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
理想执行路径应为 INDEX RANGE SCAN 或 INDEX RANGE SCAN (MIN/MAX)，且 OPERATION 列中不应出现 SORT ORDER BY STOPKEY（该步骤虽被 FETCH FIRST 限制，但仍需内存排序开销）。
⚡ 替代写法（适用于 Oracle < 12c 或需兼容性场景）
若使用较老版本或希望更精细控制，可用 ROWNUM（注意：必须嵌套子查询以确保排序生效）：
SELECT NAM, RSON, URL
FROM (
SELECT NAM, RSON, URL
FROM TM_CAM
WHERE C_NUMBER = :A_C_NUMBER
AND CA_NUMBER = :A_CA_NUMBER
AND SYSTIMESTAMP <= D_TIMESTAMP
ORDER BY D_TIMESTAMP DESC
)
WHERE ROWNUM = 1;⚠️ 注意：ROWNUM 必须在已排序的内层查询结果上应用，否则排序逻辑失效。
? 进阶方案：使用窗口函数（语义更清晰，适合复杂逻辑扩展）
当未来可能需要 Top-N 或去重逻辑时，ROW_NUMBER() 更具可维护性：
WITH ranked AS (
SELECT NAM, RSON, URL,
ROW_NUMBER() OVER (ORDER BY D_TIMESTAMP DESC) AS rn
FROM TM_CAM
WHERE C_NUMBER = :A_C_NUMBER
AND CA_NUMBER = :A_CA_NUMBER
AND SYSTIMESTAMP <= D_TIMESTAMP
)
SELECT NAM, RSON, URL
FROM ranked
WHERE rn = 1;❌ 避免的写法
如问题中尝试的子查询方式：
-- ❌ 不推荐：引发二次全表/索引扫描，且 MAX(D_TIMESTAMP) 可能返回多行，逻辑不严谨 SELECT ... WHERE D_TIMESTAMP = (SELECT MAX(D_TIMESTAMP) FROM TM_CAM) AND ...
该写法不仅性能差（需先全扫求最大值，再回表匹配），还存在业务风险：若多个记录共享同一最大 D_TIMESTAMP，可能漏数据或结果不稳定。
? 总结
- ✅ 优先创建组合索引 ON (C_NUMBER, CA_NUMBER, D_TIMESTAMP)；
- ✅ 始终通过 EXPLAIN PLAN 验证是否走索引范围扫描；
- ✅ FETCH FIRST 1 ROWS ONLY 在 12c+ 中已是最佳实践，无需替换；
- ✅ 若需兼容旧版本，用 ROWNUM 嵌套排序子查询；
- ❌ 避免 MAX() 子查询等引入额外扫描的写法；
- ? 定期检查索引统计信息是否最新（DBMS_STATS.GATHER_TABLE_STATS），防止执行计划退化。
