一、业务中普遍存在的查询性能割裂问题

日常开发做数据查询、统计时，经常会遇到一个很矛盾的性能现象：相同查询语句，仅筛选条件的值不同，响应速度天差地别，严重影响用户体验。

场景 1：图书检索系统

1. 检索小众语种图书（韩语）：库内仅 3 条数据，带索引查询秒出结果；
2. 检索英文图书：表内 99% 数据均为英文书籍，此时行存数据库优化器判定索引收益极低，直接放弃索引走全表扫描，大量无关字段加载带来巨大 IO 开销，查询严重卡顿。

场景 2：广告投放数据统计

中小广告主每日仅数千条业务记录，按用户筛选明细走索引查询速度稳定；头部广告主单日产生数千万条数据，按维度汇总统计时，纯行存全表扫描效率断崖式下跌。

场景 3：开源项目热度分析

1. 限定单语言筛选（如 Javascript）：海量数据中筛选少量匹配记录，索引查询高效；
2. 全语言热度排行统计：需要遍历全表聚合计算，传统行存执行缓慢。

传统架构：独立行存 + 列存两套引擎的致命短板

为解决明细查询与批量分析的矛盾，很多系统会搭建行存、列存两套独立数据库，依靠 ETL 工具同步数据：

1. 行存（MySQL（InnoDB）,Oracle,PostgreSQL,SQL Server）：适配索引点查、少量明细读取、频繁增改；缺陷是全表扫描 IO 成本极高；
2. 列存（ClickHousem,Snowflake,Apache Druid,Google BigQuery）：按列压缩存储，仅读取查询所需字段，适合批量扫描、聚合统计；缺陷是单行精准检索性能弱。

但该架构存在无法根治的硬伤： 应用层必须人工判断当前 SQL 适合路由到行存还是列存，没有统一调度能力。一旦筛选条件发生变化（小众值查询变为全量统计），最优存储引擎随之切换，代码无法自适应，性能波动问题无法从根源解决。

二、TiDB 一体化架构：一份数据，统一 SQL 引擎，兼顾行存与列存

OSS Inside 没有采用传统双库分离方案，而是基于 TiDB 原生能力构建统一数据层，核心设计：

1. 底层双存储副本：TiKV 作为行存版本，TiFlash 作为列存版本；
2. 全局统一 SQL 入口：仅有一套 KV Server 作为 SQL 执行引擎；
3. 数据同源同步：TiKV、TiFlash 是同一份数据的两个副本，两边数据实时一致，无需额外 ETL 同步两套库；
4. 内置智能优化器：自动评估 SQL 执行计划，无需业务代码干预路由逻辑。

优化器自动路由规则

• 场景 A：海量数据筛选少量结果、存在有效索引 → 自动下发至 TiKV 行存执行，利用索引快速定位匹配数据；
• 场景 B：大范围全表扫描、全维度聚合统计 → 自动切换 TiFlash 列存执行，依靠列式压缩降低磁盘 IO，提升批量计算效率。

三、OSS Inside 实战演示：49 亿行数据表的两种查询验证

我们以 TiDB 中数据规模最大的github_events表做实测，整张表存储49 亿行开源事件数据。

1. 精准筛选场景：统计编程语言为 Javascript 的事件总量 SQL 携带精准过滤条件，匹配数据约 1 亿多行，优化器识别为索引查询场景，自动路由 TiKV 执行，查询秒级返回；
2. 全量统计场景：不限制编程语言，统计全部项目热度数据 该语句等价全表扫描，优化器判断索引无收益，直接下发至 TiFlash 列存扫描计算，无需遍历完整行数据，查询依旧高速返回。

查看两条 SQL 的执行计划可以清晰区分：精准过滤走 TiKV 行存，全局聚合自动切换 TiFlash 列存，全程无需开发手动指定存储引擎。

四、方案价值总结

回到最初图书检索系统的痛点做对比：如果业务系统采用 TiDB 一体化架构，一套 SQL 引擎统一接管所有查询，底层自动切换 TiKV/TiFlash，切换检索条件时不会出现性能骤降、用户体验变差的问题。

OSS Inside 基于 TiDB 实现的一体化存储查询架构，彻底解决了传统 “行存 + 列存双库” 需要人工适配数据源的尴尬，统一 SQL 入口、自动路由执行计划，兼顾明细点查与海量数据分析两种核心场景，大幅降低业务开发适配成本，提升研发敏捷度。