DeepSeek Api
📌 存储方案设计
CREATE TABLE deepseek_responses (
id VARCHAR(36) PRIMARY KEY COMMENT 'UUID主键',
object VARCHAR(20) NOT NULL COMMENT '对象类型',
created BIGINT NOT NULL COMMENT '时间戳',
model VARCHAR(50) NOT NULL COMMENT '模型名称',
system_fingerprint VARCHAR(50) COMMENT '指纹标识',
-- 核心动态数据存JSON
choices JSON NOT NULL COMMENT '响应内容数组',
-- 元数据字段
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;🔍 关键设计解析
1. 混合存储策略
2. JSON字段优势
精准提取内容：
sql
复制
-- 提取第一条内容的delta.content SELECT JSON_UNQUOTE(JSON_EXTRACT(choices, '$[0].delta.content')) FROM deepseek_responses WHERE id = 'dcc6c6fb-...';索引优化（针对高频查询字段）：
sql
复制
-- 对created字段建索引 CREATE INDEX idx_created ON deepseek_responses (created);
3. 字符集与性能
强制使用
utf8mb4：确保存储表情符号（如😊）、Markdown符号（**）时无乱码空间优化：主字段拆解后，JSON仅存动态部分，减少冗余存储
🛠 写入示例
INSERT INTO deepseek_responses (
id, object, created, model, system_fingerprint, choices
) VALUES (
'dcc6c6fb-02a2-4335-aa7a-b4b8cad1c2d5',
'chat.completion.chunk',
1742977111,
'deepseek-chat',
'fp_3d5141a69a_prod0225',
-- JSON数组直接存储
'[{"index":0,"delta":{"content":"？"},"logprobs":null,"finish_reason":null}]'
);⚡ 性能对比
📝 最终建议
必做：确认MySQL版本 ≥ 5.7.8（支持JSON类型）
必做：JDBC连接串添加
useUnicode=true&characterEncoding=utf8mb4选做：若需频繁按
delta.content搜索，可添加生成列：sql
复制
ALTER TABLE deepseek_responses ADD COLUMN first_content TEXT GENERATED ALWAYS AS ( JSON_UNQUOTE(JSON_EXTRACT(choices, '$[0].delta.content')) STORED; CREATE INDEX idx_first_content ON deepseek_responses (first_content(20));
此方案在存储效率、查询性能和扩展性之间实现了最佳平衡，特别适合聊天分块响应的结构化存储场景。
以下是对该SQL代码的逐层解析：
📌 代码功能概述
sql
复制
-- 添加生成列提取JSON内容
ALTER TABLE deepseek_responses
ADD COLUMN first_content TEXT GENERATED ALWAYS AS (
JSON_UNQUOTE(JSON_EXTRACT(choices, '$[0].delta.content'))
) STORED;
-- 为生成列创建前缀索引
CREATE INDEX idx_first_content ON deepseek_responses (first_content(20));🧠 逐关键字解析
1. ALTER TABLE 部分
2. CREATE INDEX 部分
🔍 关键设计原理
1. 为什么需要生成列？
痛点：直接查询JSON字段中的
delta.content需每次解析，性能差解决方案：通过生成列将JSON内容物化存储，查询时无需解析
2. STORED vs VIRTUAL
3. 前缀索引长度选择
公式参考：
索引长度 ≥ log(总记录数)/log(平均重复率)经验值：对于普通中文文本，前20字符可覆盖大部分唯一性场景
验证方法：
-- 计算前20字符的唯一性比例
SELECT
COUNT(DISTINCT LEFT(first_content,20)) / COUNT(*) AS uniqueness
FROM deepseek_responses;⚠️ 潜在问题与规避
1. JSON路径错误
现象：若
choices数组为空或路径不存在，first_content值为NULL
防御方案：
-- 修改生成列表达式，增加默认值
GENERATED ALWAYS AS (
COALESCE(
JSON_UNQUOTE(JSON_EXTRACT(choices, '$[0].delta.content')),
''
)
)2. 索引失效场景
WHERE条件：
WHERE first_content LIKE '%关键词%'（前导通配符导致索引失效）优化方案：改为
WHERE first_content LIKE '关键词%'
3. 字符集问题
确保一致性：需确认表字符集为
utf8mb4，否则中文/表情符号会被截断
📊 性能对比示例
🛠️ 最佳实践建议
版本要求：MySQL ≥ 5.7（支持生成列）
监控调整：定期检查索引选择性，适时调整前缀长度
写入优化：批量插入时建议临时禁用索引，完成后重建
ALTER TABLE deepseek_responses DISABLE KEYS;
-- 批量插入操作 --
ALTER TABLE deepseek_responses ENABLE KEYS;最终优化版 SQL
sql
复制
CREATE TABLE deepseek_dialogue (
id BIGINT UNSIGNED AUTO_INCREMENT COMMENT '自增主键（支持更大范围）'
PRIMARY KEY,
session_id VARCHAR(36) NOT NULL COMMENT '会话UUID（替代rank_id更通用）',
role ENUM('user','assistant','system') NOT NULL COMMENT '角色枚举',
user_id BIGINT UNSIGNED NOT NULL COMMENT '用户ID（兼容64位系统）',
-- 核心内容提取
content TEXT GENERATED ALWAYS AS (
JSON_UNQUOTE(JSON_EXTRACT(chat_message, '$.content'))
) STORED COMMENT '消息内容（从chat_message提取）',
-- JSON字段优化
chat_message JSON NOT NULL COMMENT '对话数据（结构示例：{"content":"hello","type":"text"}）',
metadata JSON NOT NULL COMMENT '元数据（原more_detail_message更名）',
-- 状态字段强化
status TINYINT NOT NULL DEFAULT 1 COMMENT '状态：0-异常 1-正常 2-审核中',
-- 时间字段自动化
create_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT '创建时间（毫秒精度）',
update_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '更新时间',
-- 索引区域
INDEX idx_user_session (user_id, session_id),
INDEX idx_content_prefix (content(20)),
INDEX idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
COMMENT='对话记录表（优化版）';🔍 优化点详解
1. 字段重构
2. JSON字段优化
内容提取：通过生成列自动提取
chat_message.content到独立字段sql
复制
-- 生成列定义（STORED类型提升查询性能） content TEXT GENERATED ALWAYS AS (...)结构注释：明确JSON字段结构示例，降低维护成本
sql
复制
COMMENT '{"content":"hello","type":"text"}'
3. 时间精度升级
DATETIME(3)：支持毫秒级时间记录（如2023-08-01 12:34:56.789）自动更新：
update_time字段自动跟踪记录变更sql
复制
DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3)
4. 索引策略
5. 存储引擎强化
ENGINE=InnoDB：默认支持事务和行级锁字符集：
utf8mb4_unicode_ci支持所有Unicode字符（含emoji）
⚡ 性能对比
📝 升级步骤建议
数据迁移（示例）：
sql
复制
INSERT INTO new_table SELECT id, UUID() AS session_id, -- 需根据业务生成真实session_id role, user_id, chat_message, more_detail_message AS metadata, COALESCE(status,1) AS status, -- 处理NULL值 create_time, update_time FROM old_table;灰度验证：
先在新表写入部分数据
对比新旧表查询性能
使用
EXPLAIN验证索引命中
兼容性处理：
sql
复制
-- 临时视图兼容旧查询 CREATE VIEW legacy_dialogue AS SELECT id, session_id AS rank_id, ... FROM deepseek_dialogue;
⚠️ 注意事项
枚举类型扩展：若需新增角色类型，需执行DDL操作：
sql
复制
ALTER TABLE deepseek_dialogue MODIFY role ENUM('user','assistant','system','admin');生成列维护：若修改
chat_message结构，需同步更新生成列表达式索引长度监控：定期检查前缀索引选择性：
sql
复制
SELECT COUNT(DISTINCT LEFT(content,20))/COUNT(*) AS selectivity FROM deepseek_dialogue; -- 建议选择性 > 0.9 时保持当前长度
