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

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

这就不太对了。几千行的表，哪怕 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。从代码可读性上看，确实有很多可以改的地方。问题是，数据库不按人的阅读体验执行。

我一开始对数据平台的理解很直接：把数据接进来，存到库里，再提供页面、报表或者接口给别人用。

做过以后，发现这个理解太简单了。

报表和页面在很靠后的位置。麻烦的事情在前面：数据从哪里来，字段是谁定义的，谁负责解释口径，多久刷新一次，谁可以消费，接口申请有没有审批，质量规则失败以后谁处理，整个数据量越来越大以后如何管理。

这些问题如果只靠文档和人工沟通，平台很快就会变成一个更大的“查数入口”。页面很多，表很多，数据很多，但每一次字段变化、规则失败、接口异常，还是靠人去问、靠日志去翻。

这篇文章不是讲完整的数据治理理论。我只记录自己在内部数据平台项目里碰到过的几个具体问题，以及后来为什么会觉得：数据平台要管理的不是页面，而是数据关系。