干了十多年数据库运维，我见过太多项目上线时各种指标都很好看，但跑上几个月之后就完全变了样：磁盘空间报警、报表查询越来越慢、业务方天天抱怨“数据都在库里，为什么就是调不出来”。这种问题不是数据库“容量不够”，本质上是数据利用率太低了。最近我在几个 YashanDB 项目上做了同样的“瘦身+提速”整理，效果很直接，正好把实操经验整理成一篇。
这篇内容不是教你怎么装库、怎么建表，而是聚焦“怎么让 YashanDB 里已经存着的数据真正被查得快、用得好、管得省”。适合正在用 YashanDB 做生产系统维护的 DBA、数据架构师，以及被业务方追着要报表的开发同学。你不需要对 YashanDB 有特别深的研究，只要配合几个核心思路和 SQL 案例，回去就能在测试环境里动手验证。
1. 别急着加机器，先定位数据利用率低在哪
大部分人一听到“数据利用率低”，第一反应是磁盘空间不够，或者性能不行，然后就开始规划加存储、加节点。但我踩过几次坑之后可以很肯定地说，大多数情况下问题不是硬件不够，而是数据组织和访问方式出了问题。
1.1 数据利用率问题不是“容量不够”，而是“用不起来”
所谓数据利用率，我的理解是两层：
- 存储利用率：数据占着空间，到底有多少是被高频查询、报表、分析任务真实访问的？那些半年甚至一年都没人碰的历史数据，是不是还在和生产数据抢磁盘和缓存？
- 访问利用率：一条查询发到数据库，数据库是走了索引、快速返回结果，还是把整张大表从头到尾扫一遍？同样的数据，查询效率差出几十倍，这比“空间不够”更致命。
YashanDB 这类企业级数据库，存储和计算分离或者本地盘的架构各有不同，但共同点是：数据量到一定规模后，如果不去做分层、不去管访问路径，系统就会把大量资源花在“本来不该花的活儿”上。
我建议你先别一头扎进参数调优里，先做一次“数据使用体检”：看看库里最大的几十张表分别多大、最近一个月有没有被访问过、哪些 SQL 经常全表扫描、慢 SQL 排行榜前几名都是谁。做完这一步，方向自然就清楚了。
1.2 三类最常见的浪费场景：冷热不分、扫描放大、统计失真
这几年我复盘过的 YashanDB 性能问题，基本都能归到这三类：
冷热不分是我见过最多的一类。业务表设计时图省事，一张流水表从上线第一天存到现在，里面可能有好几年的历史数据。报表查询明明只需要最近三个月，但因为没做分区或者分区没用好，数据库只能扫描整个大表，缓存被冷数据疯狂挤占，性能自然上不去。
扫描放大则是 SQL 写法或者索引设计的问题。条件字段上明明有索引，但由于函数包裹、隐式类型转换、或者统计信息过期，优化器就是选择不走索引，结果一条简单查询变成了全表扫描。数据量一大，IO 和 CPU 立刻被打满。
统计失真最隐蔽。YashanDB 的优化器和其他主流数据库一样，依赖统计信息来估算行数和成本。如果每次大批量写入后没有及时更新统计信息，优化器掌握的数据分布还是上周的，执行计划就会跑偏。一个本应走索引的查询，可能因为估算错误变成嵌套循环加全表扫描。
这三种问题，光靠加机器解决不了，得从数据组织、索引策略、统计信息这几个根子上入手。
2. 存储与生命周期管理：把冷热数据分开，先把该省的省下来
很多 YashanDB 实例磁盘爆满，不是数据真的多到装不下，而是冷热数据混在一起，谁都没法有效利用空间。这一节讲怎么从存储和组织层面把利用率提上去。
2.1 分区表设计与冷热分级
分区表是解决冷热数据混杂最直接的手段。YashanDB 支持常见的 range、list、hash 分区，日常业务场景里，流水类数据用范围分区（按时间）最自然。
举个例子，订单表如果按月分区，DDL 大概是这样（以兼容模式为例）：
CREATE TABLE orders ( id NUMBER, order_no VARCHAR2(64), customer_id NUMBER, order_date DATE, amount NUMBER(12,2) ) PARTITION BY RANGE (order_date) INTERVAL(NUMTOYMINTERVAL(1, 'MONTH')) ( PARTITION p_first VALUES LESS THAN (TO_DATE('2024-01-01', 'YYYY-MM-DD')) );INTERVAL 分区的好处是，每个月的数据进入时自动创建新分区，不用 DBA 手动维护。关键是查询条件里带上分区键，比如 WHERE order_date >= DATE '2025-01-01'，优化器就能直接做分区裁剪，只扫最近几个月的数据，而不是整张表。
这套设计带来的收益，不只是查询快，还给后续的数据生命周期管理留了口子：
- 超过两年的分区可以改成只读，防止意外修改。
- 更老的分区可以迁移到慢速存储或者归档表。
- 清理数据时直接 TRUNCATE 分区，比 DELETE 快几个数量级。
我自己的习惯是，新表设计阶段就强制要求业务方给出保留周期。如果没有保留周期，那至少留一个时间字段做分区键，否则后面想改分区，代价就大了。
2.2 压缩与归档：牺牲一点 CPU 换空间和 IO
很多人在 YashanDB 里建表时，默认参数一用到底，完全没有考虑压缩。实际上，对于日志型、流水型数据，压缩可以大幅降低存储占用，读取时也能减少 IO。
需要注意，压缩不是没有代价的。写入和读取时需要进行压缩/解压运算，会消耗 CPU。但在分析类场景，大量顺序扫描下，压缩后的数据量小了，IO 时间省下来，整体性能往往反而更好。
我一般这样处理：
| 数据类型 | 建议做法 | 理由 |
|---|---|---|
| OLTP 高频交易表 | 不压缩或低级压缩 | 写入延迟敏感，避免CPU开销 |
| 流水/日志型大表 | 中等级压缩 | 空间收益明显，查询频率适中 |
| 历史归档分区 | 高等级压缩 | 很少更新，只读为主，压得越狠越划算 |
如果 YashanDB 表创建时支持 COMPRESS 选项，可以对历史分区单独设置更高压缩级别。注意，压缩尽量在建表或分区级别设置，不要等数据量大了再频繁修改，重写表代价不小。
归档方面，我常用的方案是：对超过 N 个月的分区，先通过 CTAS（CREATE TABLE AS SELECT）抽出到归档表，再从原表删除或 TRUNCATE 对应分区。归档表可以放到不同的表空间、不同的存储介质上。真要查历史数据时，业务方访问归档视图，生产库的压力完全不受影响。
2.3 清理与回收：避免“删了不回收”
这类坑特别常见。有人用 DELETE 删掉了几百万行历史数据，看表里的数据量确实少了，但磁盘空间一点没释放。原因很简单：DELETE 只是标记数据不可见，存储段的高水位线还在，空间没有归还给系统。
所以，如果你确实要清理数据，我的优先级建议是：
- 按分区 TRUNCATE，最快，空间立即释放。
- 整表清空，用 TRUNCATE。
- 非分区表删部分数据，DELETE 后必须重新收集统计信息，并考虑整理表空间碎片。
YashanDB 的段空间管理如果支持自动收缩，可以查一下当前版本是否支持在线收缩段。如果支持，用类似 ALTER TABLE ... SHRINK SPACE 的语法把多余空间释放掉；如果不支持，可以评估用 exp/导入导出方式重建表。
但无论如何，最省心的方案都是从一开始就用分区表，让“清理”变成“丢分区”，而不是“删数据”。这一点再强调一遍都不为过。
3. 索引与执行计划：让查询走最短路径，而不是全表乱翻
存储层把数据归置好了，下一步就是访问路径的优化。这一部分直接决定 SQL 的执行效率，也是提升 YashanDB 数据利用率最立竿见影的环节。
3.1 索引不是越多越好：怎么判断索引真的被用上了
很多开发同学有个习惯，WHERE 里出现一个字段就建一个单列索引。结果一张表建了十几个索引，每个索引都占空间，INSERT/UPDATE 时还要同步维护。问题是这些索引真的被用到了吗？
我判断索引有效性的方法很土，但很管用：定期去查数据库里执行次数最多、消耗最大的 SQL，把它们的 WHERE 条件、JOIN 条件、ORDER BY 字段提出来，看现有索引是否匹配。没有业务查询做支撑的索引，大部分都是废索引。
有效索引设计不等于“多建索引”，而是“建对的索引”。比如：
SELECT customer_id, order_date, amount FROM orders WHERE customer_id = 1001 AND order_date >= DATE '2025-01-01' ORDER BY order_date DESC;这种情况下，复合索引 (customer_id, order_date) 通常比分开建两个单列索引效果更好。复合索引可以让查询一次定位到客户 1001 在指定日期范围内的数据，并且通过索引排序避免额外的排序操作。
还要注意索引列顺序。等值条件的列放前面，范围条件的列放后面，这样索引才能最大化发挥作用。如果你把 order_date 放前面、customer_id 放后面，查询能用到索引，但过滤效率就差很多。
3.2 统计信息收集：优化器不知道数据分布，计划就是盲猜
YashanDB 的优化器和你见过的其他数据库优化器没有本质区别，它的核心工作是基于统计信息和成本模型选择执行计划。统计信息不准，一切索引设计都白搭。
有一次我在一个 YashanDB 环境排查慢 SQL，开发那边坚称“索引建了，没问题”。结果我一看执行计划，走的全表扫描。再一查统计信息，上次收集时间已经是大半年前。大批量数据导入之后，统计信息完全没有更新。优化器拿着老黄历估算，认为全表扫描比走索引更便宜，自然就不走索引了。
解决方式很直接：
-- 收集某个表统计信息 EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'ORDERS'); -- 收集某个 schema 下所有表 EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCHEMA_NAME');建议的策略是：
- 大批量数据加载（ETL/导入）完成后，立即收集统计信息。
- 每天凌晨低峰期跑一次全库/schema 统计信息收集任务。
- 不要每次小事务都收集，太频繁只会浪费资源。
如果你发现有些 SQL 统计信息明明正常，执行计划还是不对，可以尝试用 hint（比如 /*+ INDEX(orders idx_orders_customer_date) */）或者改写 SQL 让优化器做出正确选择。但 hint 是双刃剑，一般作为短期手段，长期还是要找到统计信息或 SQL 本身的问题。
3.3 SQL 改写与执行计划排查实操
很多慢 SQL 根子不在数据库，而是 SQL 写得不够好。这里分享几个我在 YashanDB 日常优化中反复用到的改写技巧：
避免 SELECT *。只查需要的字段。SELECT * 会让数据库读取整行数据，如果有大字段（比如很长的文本字段），IO 开销大得离谱。养成按需取列的习惯，对利用率提升立竿见影。
不要在 WHERE 条件中的列上做函数运算。比如 WHERE TO_CHAR(order_date, 'YYYY-MM') = '2025-06'，看起来没问题，但函数把索引列包住了，优化器无法正常走索引。改写为 WHERE order_date >= DATE '2025-06-01' AND order_date < DATE '2025-07-01'，同样的结果，性能天差地别。
LIKE 模糊匹配慎用前缀通配符。WHERE name LIKE '%张%' 基本无法有效利用索引，如果业务确实需要频繁做这种搜索，请考虑全文检索或独立搜索引擎，不要让数据库硬扛。
UNION 和 UNION ALL。如果两个查询结果肯定不重复，用 UNION ALL。UNION 要去重，会额外产生排序和去重开销。
分页查询。深分页场景下 LIMIT 100000, 20 这种写法会扫描前面十万行再丢弃，越到后面越慢。如果表有唯一排序键，可以改成基于游标或上一页最大值的方式。
排查执行计划是基本功。YashanDB 里最简单的做法是：
EXPLAIN PLAN FOR SELECT customer_id, COUNT(*) FROM orders WHERE order_date >= DATE '2025-01-01' GROUP BY customer_id; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);看到计划里有 TABLE ACCESS FULL 或全表扫描的迹象，就要想一想是不是索引问题、统计信息问题或者 SQL 写法问题。操作慢 SQL 时，别只看返回时间，先看执行计划和逻辑读/物理读的数字，定位到底慢在哪一步。
4. 数据分析与共享：让同一份数据被更多人安全地“用起来”
数据利用率不只是“查得快”，还包括“让更多合法、安全的业务场景能够使用同一份数据”。很多时候，数据明明很有价值，但因为取数入口太窄、报表任务太重，导致业务方根本不敢用、没法用。
4.1 视图与物化视图：用“预计算”换查询速度
视图的本质是保存 SQL 定义，本身不存储数据。它的价值在于提供统一的取数逻辑。比如业务方经常需要查“每个区域近 7 天付款订单总额”，你不需要让每个报表开发都写一遍那串复杂的汇总 SQL，而是建一个视图把这层逻辑封装好，业务方只需要 SELECT * FROM v_region_order_amount WHERE ... 就行。
但如果汇总逻辑非常重，每次查询都实时聚合几百万行，哪怕有视图，性能也扛不住。这时候就要考虑物化视图。
物化视图和普通视图最大的区别是，它会真正把计算结果存储下来。YashanDB 如果支持物化视图，你可以这样设计：
-- 伪示例，以实际支持能力为准 CREATE MATERIALIZED VIEW mv_region_daily_summary REFRESH COMPLETE ON DEMAND AS SELECT region, order_date, SUM(amount) AS total_amount FROM orders GROUP BY region, order_date;物化视图适合报表、BI、指标看板这一类对实时性要求不高的场景。刷新策略建议按业务容忍度来定：小时级、每日凌晨，或者依赖源表变化做增量刷新。注意，物化视图也要占存储空间，别把几百个物化视图全部高频刷新，否则你会从“查询慢”变成“刷新慢”。
4.2 只读备库/读写分离：别让报表拖垮生产
很多企业的做法是：生产 OLTP 主库既要处理在线交易，又要扛 BI 报表查询。白天业务高峰，报表一跑，整个库的 CPU 和 IO 立刻被拉高，交易响应也开始抖动。这种情况，即使你把单条 SQL 调得再快，本质上还是让读任务和写任务在抢同一份资源。
更合理的做法是利用 YashanDB 的备库能力做读写分离。主库承担 OLTP 写入，备库（或只读实例）承载报表、分析、查询类的读流量。DBA 在备库上做索引、统计信息优化，也不会影响主库的写入性能。
我见过不少项目因为历史原因一直没做读写分离，业务高峰期非常痛苦。如果你所在的团队已经用上了 YashanDB 的备库或者只读副本，建议优先把报表类查询切过去；如果还没有，规划新业务时最好把读流量设计进去，这比事后硬调 SQL 的收益大得多。
4.3 数据服务化与 API 封装：把数据利用率变成业务效率
数据利用率提升到一定阶段，真正的瓶颈往往不在数据库，而在取数接口。业务方需要数据时，如果每次都要现写 SQL、找 DBA 授权、手动导出，这数据再全也很难被高效利用。
我比较推荐在 YashanDB 上层做一层数据服务层，把常用查询封装成 API。比如订单查询、用户标签查询、经营报表汇总，都做成标准接口，业务系统直接调用。这样做的好处有三个：
- 权限可控：不同业务方只看到授权范围内的字段，避免数据泄露。
- 逻辑统一：同样的“有效订单”定义，不会在 A 系统和 B 系统里算出两种结果。
- 变更安全：底层表结构调整时，只需要改服务层，业务方无感知。
当然，这一层不一定要自己写很重的框架，可以先从最简单的只读账号加视图做起，再逐步过渡到 API 服务。关键是让“数据能被人方便地拿到”，而不是每次都走审批和导出流程。
5. 监控与调优：把“利用率”变成可量化的指标
最后一步，也是保证前面所有优化不反复的关键，就是建立一套可持续的监控巡检机制。没有监控，你根本不知道优化有没有效果，也不知道数据利用率是不是又悄悄掉下去了。
5.1 关键监控指标：QPS、慢 SQL、缓冲区命中率、表扫描次数
监控指标不需要贪多，我通常盯这几个：
| 指标 | 说明 | 优先级 |
|---|---|---|
| 慢 SQL 数量与耗时分布 | 直接反映用户体验和潜在问题 | 高 |
| 缓存命中率 | 逻辑读 vs 物理读，命中率低说明冷数据在挤占缓存 | 高 |
| 表扫描次数/扫描行数 | 全表扫描多，说明索引或 SQL 可能有隐患 | 高 |
| 活跃会话数 | 判断系统是否出现锁等待或资源争用 | 中 |
| 表空间增长趋势 | 提前规划容量，避免存储耗尽造成故障 | 中 |
YashanDB 一般会提供动态性能视图，比如按 SQL 维度统计执行次数、耗时、逻辑读这类信息。如果版本里带 v$SQL 或者类似视图，你可以直接按“总耗时/执行次数”排序，快速找出 TOP 慢 SQL。这类视图的字段名不同版本可能略有差异，但思路一致：找出资源消耗最大的 SQL，逐个击破。
5.2 一套可落地的巡检脚本思路
很多 DBA 的问题不是不知道要巡检，而是巡检全靠手动，想起来才跑一次。我分享一个简单的巡检策略，你完全可以用 shell 脚本加定时任务实现：
- 每天凌晨收集统计信息（全库或指定业务 schema）。
- 每天上班前生成一份“慢 SQL 排行榜”和“表空间使用报表”，发到工作群或邮件。
- 每周对比上周的数据量增长、分区数量、索引使用情况。
具体 SQL 不写了，每个版本视图不同，重点是你把以下信息定时输出：
- 单次执行超过 5 秒的 SQL 文本、执行次数、平均耗时。
- 空间占用 TOP20 表及其分区情况。
- 最近 7 天执行过全表扫描的大表名单。
- 统计信息超过 7 天未更新的表列表。
这套巡检机制本身不复杂，但坚持下去，很多性能隐患都能在业务投诉之前先暴露出来。千万别高估自己的记忆力，数据库的容量和负载增长往往比预想中快得多。
5.3 常见问题排查与故障处理记录
最后整理几个我在 YashanDB 环境下实际遇到过的“典型翻车现场”，供参考：
问题一：删了几百万历史数据，空间没释放。原因就是 DELETE 后高水位线未回收。解决办法：如果是分区表，直接 TRUNCATE 对应分区；如果是非分区表，评估收缩或重建表。
问题二：统计信息刚收集完，执行计划还是不对。这种情况往往是绑定变量窥探、或者数据分布极度倾斜导致。可以看是不是直方图缺失，对关键列重新收集直方图；实在不行再用 hint 过渡。
问题三：索引建了不少，DML 和查询反而都变慢了。原因很可能是低选择性索引太多，执行计划频繁在索引回表和全表扫描之间摇摆。对策是删掉那些长期不在执行计划里出现的索引。
问题四：报表查询占用资源过高，影响生产交易。这个前面提过，最有效的解法是把读流量迁移到只读备库或独立分析库，而不是单纯调 SQL。
每次处理完问题，我建议把时间、现象、根因、处理方案、验证结果记成“故障卡片”。下次遇到类似问题，翻出来直接按图索骥，效率比自己从头排查快得多。
我个人在实际项目里的体会是，提升 YashanDB 数据利用率，最忌讳一上来就对着参数手册做“玄学调优”。先把数据分层、分区、索引、统计信息这些基本功做扎实，再把监控巡检跑起来，大部分性能问题都能在早期被识别和消化掉。最后再说一个小细节：每次大版本升级或迁移后，别忘了重新评估索引和统计信息的采集策略，很多时候问题的源头，恰恰是新老环境里优化器行为的那一点点差异。
