这次问题最早不是从数据库指标开始的，而是流程专家找我说：有一张表查询一次要等很久。

我第一反应其实很常规：是不是查的数据量太大了？流程类系统里有些历史表一跑就是几年数据，如果查询条件再松一点，慢也不奇怪。结果他补了一句：这张表总共才几千行。

这就不太对了。几千行的表，哪怕 SQL 写得不算好，也不应该慢到让业务侧明显感知。我还是抱着质疑的态度自己执行了一下

SELECT COUNT(*)
FROM table_a;

这次问题发生在一个 Oracle 查询上。业务页面要展示一批物料在仓储流程里的状态，数据来自本地表，也来自一张通过 DB Link 访问的远程明细表。页面慢，用户看到的是转圈，开发看到的是一段很长的 SQL。

我第一次看这段 SQL 的反应很直接：太乱了，先整理一下。

它里面有 CTE，有远程表，有 CONCAT(CREATION_DATE, CREATION_TIME)，有 SUBSTR 截取库位号后 10 位，有 TO_CHAR(rm_tag, 'hh24miss') 判断班次，还有一堆状态 CASE WHEN。从代码可读性上看，确实有很多可以改的地方。问题是，数据库不按人的阅读体验执行。