低成本上下文存储（外列）

建表

在列定义末尾加上EXTERNALIZE关键字，表示这一列的数据要外置到OSS：

CREATE TABLE chat_messages (
    id         BIGINT PRIMARY KEY AUTO_INCREMENT,
    session_id BIGINT,
    user_id    BIGINT,
    role       ENUM('user','assistant','system'),
    token_count INT,
    created_at DATETIME,
    content    LONGTEXT EXTERNALIZE,
    KEY idx_session (session_id, created_at)
) PARTITION BY KEY(session_id);

加列

已有的表也可以通过ALTER TABLE加外列：

ALTER TABLE chat_messages ADD COLUMN reasoning LONGTEXT EXTERNALIZE;

支持的类型

• 文本族：TEXT / TINYTEXT / MEDIUMTEXT / LONGTEXT

• 二进制族：BLOB / TINYBLOB / MEDIUMBLOB / LONGBLOB

字符集要求列字符集省略或属于utf8家族（utf8 / utf8mb3 / utf8mb4），其他字符集会在建表时直接报错。

查看建表语句

SHOW CREATE TABLE输出的是逻辑视图：您看到的仍然是content LONGTEXT EXTERNALIZE，而不是底层物理列名。对您来说，物理实现是完全透明的。

核心收益

• 写入不变慢：KB级大列的写入延迟和直接写InnoDB一样，百KB以上大列在高并发下比InnoDB更快。

• 读取几乎无感：热读命中本地缓存，延迟与普通列查询相当。

• 运维零负担：无需对账脚本、无需手动清理OSS，引擎全自动。

场景一：多模态消息的列拆分

一个AI assistant的回复可能包含：回答正文、附件、工具调用结果、思考链。这些字段读频率不同：content每次拼上下文都要读，reasoning通常只在审计时才被访问。

CREATE TABLE chat_messages_v2 (
    id          BIGINT PRIMARY KEY AUTO_INCREMENT,
    session_id  BIGINT,
    role        ENUM('user','assistant','system'),
    token_count INT,
    created_at  DATETIME,
    content     LONGTEXT EXTERNALIZE,
    attachments LONGBLOB EXTERNALIZE,
    tool_calls  LONGTEXT EXTERNALIZE,
    reasoning   LONGTEXT EXTERNALIZE,
    KEY idx_session (session_id, created_at)
) PARTITION BY KEY(session_id);

-- 写入一条多模态消息
INSERT INTO chat_messages_v2(session_id, role, content, reasoning, token_count, created_at)
VALUES (10001, 'assistant', '回答正文...', '思考链内容...', 3500, NOW());

-- 日常拼接只读 content
SELECT content FROM chat_messages_v2 WHERE session_id = 10001 ORDER BY created_at;

-- 审计时才读 reasoning
SELECT reasoning FROM chat_messages_v2 WHERE id = 12345;

缓存粒度按列走：每个外列对应独立的OSS对象和缓存条目。

• content被反复SELECT，LRU一直把它留在本地缓存。

• reasoning没人碰，自然被淡出到OSS。

• 审计时再SELECT reasoning，回源OSS几十毫秒拉回来，调试场景完全可接受。

场景二：和AI框架对接

外列对 ORM（MyBatis/JPA）及 AI 框架（LangChain/LlamaIndex）完全透明，以Spring AI和LangChain4j为例：两种契约、两种schema，都是纯SQL。

-- 复用前面的 chat_messages 表
CREATE TABLE chat_messages (
    id         BIGINT PRIMARY KEY AUTO_INCREMENT,
    session_id BIGINT,
    user_id    BIGINT,
    role       ENUM('user','assistant','system'),
    token_count INT,
    created_at DATETIME,
    content    LONGTEXT EXTERNALIZE,
    KEY idx_session (session_id, created_at)
) PARTITION BY KEY(session_id);

public class PolarDBXChatMemory implements ChatMemory {
    private final JdbcTemplate jdbc;

    @Override
    public void add(String conversationId, Message message) {
        jdbc.update(
            "INSERT INTO chat_messages(session_id, role, content, created_at) "
            + "VALUES (?, ?, ?, NOW())",
            conversationId, message.getMessageType().name(), message.getText());
    }

    @Override
    public List<Message> get(String conversationId, int lastN) {
        return jdbc.query(
            "SELECT role, content FROM chat_messages WHERE session_id = ? "
            + "ORDER BY created_at DESC LIMIT ?",
            (rs, i) -> toMessage(rs.getString("role"), rs.getString("content")),
            conversationId, lastN);
    }

    @Override
    public void clear(String conversationId) {
        jdbc.update("DELETE FROM chat_messages WHERE session_id = ?", conversationId);
    }
}

CREATE TABLE chat_memory_store (
    session_id BIGINT PRIMARY KEY,
    messages   LONGTEXT EXTERNALIZE
);

public class PolarDBXChatMemoryStore implements ChatMemoryStore {
    private final JdbcTemplate jdbc;

    @Override
    public List<ChatMessage> getMessages(Object sessionId) {
        String json = jdbc.query(
            "SELECT messages FROM chat_memory_store WHERE session_id = ?",
            rs -> rs.next() ? rs.getString(1) : null, sessionId);
        return json == null ? List.of() : ChatMessageDeserializer.messagesFromJson(json);
    }

    @Override
    public void updateMessages(Object sessionId, List<ChatMessage> messages) {
        String json = ChatMessageSerializer.messagesToJson(messages);
        jdbc.update(
            "INSERT INTO chat_memory_store(session_id, messages) VALUES (?, ?) "
            + "ON DUPLICATE KEY UPDATE messages = VALUES(messages)",
            sessionId, json);
    }

    @Override
    public void deleteMessages(Object sessionId) {
        jdbc.update("DELETE FROM chat_memory_store WHERE session_id = ?", sessionId);
    }
}

DDL

DQL / DML

当WHERE条件或UPDATE SET涉及外列时，SQL不会下推到数据节点（DN）执行，而是在计算节点（CN）侧完成，执行代价和耗时可能会增加。实际使用中，大字段通常按主键定位，这个限制一般不会成为瓶颈。

小列写入（KB级）

小列走staging路径，写入就是一次数据节点（DN）本地的InnoDB INSERT。只要没有触发反压（staging表积压达到阈值），写入延迟和直接写InnoDB完全一致，对KB级大列的场景非常友好。

大列写入（百KB以上）

大字段直写OSS方案的写入性能受数据大小与并发度的双重驱动。测试表明，外列直写与传统 InnoDB之间存在一个明确的性能拐点（Crossover Point）：

• 性能拐点大幅提前：在单线程下，数据量达500 KB 时外列方案开始超越InnoDB；而在64并发下，该拐点提前至300 KB；至256并发时，拐点进一步降至140 KB。并发度越高，外列获得优势的起点越低。

• 突破I/O天花板：跨越拐点后，两者的差距呈指数级拉大。在大字段与高并发的双重压力下，InnoDB会迅速触及磁盘I/O瓶颈并陷入剧烈的锁竞争，导致吞吐量不增反降。而外列方案的主表仅写入数十字节的地址指针，绕过了这一物理限制。

• 场景对比：在“2 MB 数据 / 256 并发”的高负载场景下，InnoDB的平均延迟已飙升至5.5秒，P99 延迟突破16秒，实际已丧失生产可用性。而外列方案仍能稳定输出478 QPS的吞吐量，平均延迟控制在514毫秒，表现出极强的健壮性。

热读

热读路径上外列和InnoDB各有优劣，整体大致持平。实测16并发下，100 KB列上InnoDB更快，500 KB起外列更快。

但热读上外列有一个隐性优势：不挤占数据节点（DN）的Buffer Pool。InnoDB读大列时整个LOB页会塞进Buffer Pool，这些“读一次就不再热”的大页把索引页和热数据挤出去，同库TP业务跟着变慢。外列从计算节点（CN）本地缓存读取，不经过数据节点（DN）的Buffer Pool，索引页常驻不受影响。

代表性数据点

冷读（本地缓存MISS后从OSS回源）主要是一个OSS GET的固定开销 + 数据传输时间，100 KB约28 ms、1 MB约95 ms。业务对冷读延迟敏感的场景可考虑提前预热。