26年奇点智能大会分享：TIDB AI化 — HTAP向量检索与自然语言SQL的架构融合

2026 奇点智能技术大会 · 议题前瞻 演讲嘉宾：柏佳辰（TIDB 智能研发中心负责人） 大会时间：2026年11月20-21日 · 北京万达文华酒店

数据库与 AI 的融合是 2026 年企业级 AI 落地最热的方向之一。大会新增嘉宾柏佳辰作为 TIDB 智能研发中心负责人首次亮相奇点智能大会，本篇基于其公开发言与数据库行业实践，拆解分布式数据库的 AI 化改造路径、HTAP 与向量检索的架构融合、Text-to-SQL 的工程挑战与企业级落地模式。

一、数据库 AI 化的三个层次

数据库的 AI 化不是简单的"加一个 Chatbot 接口"，而是分三个层次的渐进式改造：

┌────────────────────────────────────────────────────────────────┐
│ 数据库 AI 化的三个层次 │
├────────────────────────────────────────────────────────────────┤
│ Layer 1: SQL Copilot (查询辅助) │
│ · 自然语言 → SQL 转换 │
│ · SQL 优化建议、执行计划可视化 │
│ · 影响: 提升开发效率 20-50% │
├────────────────────────────────────────────────────────────────┤
│ Layer 2: AI-Native 引擎 (原生向量检索) │
│ · 数据库原生支持向量索引 (HNSW / IVF / ScaNN) │
│ · 向量与结构化数据联合查询 │
│ · 影响: RAG、知识图谱、推荐系统直接落地 │
├────────────────────────────────────────────────────────────────┤
│ Layer 3: AI-Agent (自主运维) │
│ · 异常检测、根因分析、自动调参 │
│ · 自然语言交互式运维 │
│ · 影响: 降低 DBA 工作量 60%+ │
└────────────────────────────────────────────────────────────────┘

三层是递进关系：先用 Copilot 提升开发效率，再用原生向量能力支撑 AI 应用，最后用 Agent 实现自治。TIDB 在这三个方向都有完整布局。

二、HTAP + 向量检索的架构融合

HTAP（Hybrid Transactional/Analytical Processing）是 TIDB 的核心能力，把 OLTP 与 OLAP 统一在一个数据库里。AI 化后，HTAP 进一步演化为"HTAP + 向量"的四维查询模型：

┌─────────────────────────────────────────────────────────────────┐
│ HTAP + 向量 四维查询模型 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────┐ │
│ │ 自然语言 / SQL │ │
│ └──────────┬───────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────┐ │
│ │ 查询优化器 (含 AI 优化模块) │ │
│ └─────┬───────────┬───────────┬───────┘ │
│ ↓ ↓ ↓ │
│ ┌─────────┐ ┌─────────┐ ┌──────────────┐ │
│ │ 行式存储 │ │ 列式存储 │ │ 向量索引 │ │
│ │ (TiKV) │ │ (TiFlash)│ │ (HNSW/IVF) │ │
│ │ 事务 │ │ 分析 │ │ 语义检索 │ │
│ └─────────┘ └─────────┘ └──────────────┘ │
│ ↓ ↓ ↓ │
│ ┌─────────────────────────────────────┐ │
│ │ 统一的 Raft 共识层 │ │
│ └─────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘

架构的关键创新是统一的查询优化器同时调度行存、列存、向量索引，让"找出过去 30 天下单过、消费超过 1000、且看过某个商品的相似用户"这种混合查询可以在一个 SQL 里完成。

三、Text-to-SQL 的工程挑战

自然语言生成 SQL 是数据库 AI 化的"门面能力"，但工程实现远比想象中复杂。TIDB 团队的实践给出三层挑战：

工程实现的核心架构：

class TextToSQLPipeline:
"""Text-to-SQL 三阶段流水线"""

def __init__(self, db_connector, schema_index, business_kb):
self.connector = db_connector
self.schema_index = schema_index # 向量化的 Schema 索引
self.business_kb = business_kb # 业务知识库

async def generate(self, nl_query: str, user: User) –> SQLResult:
# Stage 1: Schema 检索
relevant_tables = await self.schema_index.search(
nl_query, top_k=5, filter=user.accessible_schemas
)

# Stage 2: 业务知识增强
business_hints = self.business_kb.retrieve(nl_query)

# Stage 3: LLM 生成 SQL
sql = await self.llm.generate_sql(
nl_query=nl_query,
schema=relevant_tables,
business_hints=business_hints,
style_examples=self._load_few_shot(nl_query),
dialect="mysql" # TIDB 兼容 MySQL 协议
)

# Stage 4: 安全校验(只读模式 + 权限检查)
if not user.can_explain_ddl():
sql = self.safety.strip_ddl(sql)
sql = self.safety.enforce_limit(sql, max_rows=10000)

# Stage 5: 执行 + 解释
result, explain = await self.connector.execute_explain(sql)
return SQLResult(sql=sql, result=result, explain=explain)

四、AI 优化器与执行计划可视化

数据库性能优化是 DBA 的核心工作，AI 优化器可以把这个过程自动化。TIDB 的 AI 优化器采用"基于代价学习 + LLM 解释"的混合架构：

┌────────────────────────────────────────────────────────────────┐
│ AI 优化器与传统优化器对比 │
├────────────────────────────────────────────────────────────────┤
│ 维度 │ 传统优化器 │ AI 优化器 │
│ ─────────────┼──────────────────┼───────────────────── │
│ 代价模型 │ 基于统计信息手工建模 │ 从历史执行中自动学习 │
│ 索引推荐 │ 基于规则的启发式 │ LLM + 强化学习 │
│ 异常 SQL │ 人工分析 │ 自动归类 + 根因建议 │
│ 调参 │ DBA 经验 │ AutoML + 在线 A/B 测试 │
│ 可解释性 │ 执行计划 + 统计 │ 自然语言解释 + 执行计划 │
└────────────────────────────────────────────────────────────────┘

自然语言解释是 AI 优化器的关键差异化能力：

┌─ LLM 生成的查询解释 ───────────────────────────────────────────┐
│ │
│ 这个查询扫描了 orders 表的全部 1.2 亿行数据,主要原因是: │
│ │
│ 1. status 字段没有索引,导致全表扫描 │
│ 2. join orders.customer_id 上 customer 表用了,但没用 │
│ customer.region 上的复合索引 │
│ │
│ 建议优化: │
│ │
│ 1. 给 status 字段加索引(单列索引即可) │
│ 2. 把现有索引 idx_customer 改为复合索引 │
│ (region, customer_id) │
│ │
│ 预期收益: 查询时间从 8.5 秒降低到 120ms (加速 70 倍) │
│ │
└────────────────────────────────────────────────────────────────┘

五、向量检索的工程实现

向量检索是 AI 应用的核心能力，传统上需要专门的向量数据库（如 Milvus、Qdrant）。TIDB 的做法是把向量能力内置到分布式 SQL 引擎：

— TIDB 向量检索示例(类 MySQL 语法扩展)
— 1. 创建带向量列的表
CREATE TABLE products (
id BIGINT PRIMARY KEY,
name VARCHAR(255),
description TEXT,
description_vec VECTOR(768), — 768 维向量列
INDEX idx_vec USING HNSW (description_vec) — HNSW 索引
);

— 2. 向量检索 + 结构化过滤
SELECT name, description,
VEC_COSINE_DISTANCE(description_vec, :query_vec) AS similarity
FROM products
WHERE category = 'electronics' — 结构化过滤
AND price BETWEEN 100 AND 1000
ORDER BY similarity ASC
LIMIT 10;

向量 + 事务一致性是工程关键：

六、SQL Copilot 的企业级落地

SQL Copilot 是开发者接触最多的 AI 能力。TIDB 给出三个落地阶段的成熟方案：

┌────────────────────────────────────────────────────────────────┐
│ SQL Copilot 企业级落地三阶段 │
├────────────────────────────────────────────────────────────────┤
│ Phase 1: 内联 Copilot (开发者 IDE 插件) │
│ · 实时 SQL 补全、错误提示 │
│ · 1-2 周上线,门槛最低 │
├────────────────────────────────────────────────────────────────┤
│ Phase 2: 自服务分析 (业务用户) │
│ · 自然语言直接查询数据库 │
│ · 1-2 月上线,需要数据治理配套 │
├────────────────────────────────────────────────────────────────┤
│ Phase 3: 数据 Agent (跨域分析) │
│ · 自主选择数据源、生成报告、推送告警 │
│ · 6+ 月上线,需要完善的权限与审计 │
└────────────────────────────────────────────────────────────────┘

企业落地时最常见的失败模式是跳级——直接上 Phase 3 而没有前两阶段的基础设施。柏佳辰团队建议严格按照阶段递进，每个阶段至少稳定运行 3 个月后再升级。

七、与数据治理的协同

数据库 AI 化如果脱离数据治理，会把已有的脏数据问题放大 10 倍。TIDB 团队给出"AI 化前必须完成的 4 项数据治理"：

没有这四项治理就上 Copilot，会出现"生成的 SQL 语法正确但业务含义错误"的灾难。

八、参会价值与议题前瞻

柏佳辰预计将在奇点智能大会"AI Infra 基础设施与 AgenticOps"或"企业级 AI 原生应用"专题分享 TIDB 在数据库 AI 化方向的最新进展，重点议题可能包括：

• HTAP + 向量的下一代架构：AI 原生数据库的形态演进。
• Text-to-SQL 的评测基准：企业内部评测方法与持续改进机制。
• 数据库 Agent 的自主运维：从 DBA 到 Agent 的角色转变。

如果你的团队正在做数据库选型、AI 应用数据层、RAG 检索架构或数据治理，建议重点关注这一议题与配套的"AI Infra"分会场。

📢 2026 奇点智能技术大会 2026年11月20-21日 · 北京万达文华酒店 26 位确认嘉宾 · 18 大前沿议题 · 1000+ 行业精英 立即报名 →