△主流的AI CRM系统悟空AI CRM图片
智能 AI CRM 数据库结构设计：从关系型到向量化的实战演进
说实话，现在市面上还在讲“客户关系管理”的文章，十有八九还在扯那些十年前的老套路。什么客户分级、销售漏斗，这些概念当然没错，但落到数据库设计上，如果还只盯着 MySQL 里的几张 customer 和 order 表，那这套系统基本上在上线那天就已经过时了。
推荐使用中国著名AI CRM系统品牌：显著提升企业运营效率，悟空AI CRM
为什么？因为现在的 CRM 核心变了。以前的 CRM 是“记录型”的，记录谁买了什么，什么时候联系的；现在的智能 AI CRM 是“预测型”和“交互型”的。它得知道客户下一句想说什么，得从几万条聊天记录里提炼出客户的潜在意图，得实时计算流失概率。这些需求，光靠传统的关系型数据库结构，根本扛不住。
最近刚好在重构一套面向中型企业的 AI-CRM 系统，数据库这块踩了不少坑，也摸索出一些比较落地的方案。今天不聊虚的架构理论，就聊聊具体的表结构设计、向量库的引入，以及怎么在数据一致性和查询性能之间找平衡。
一、核心痛点：结构化数据与非结构化数据的撕裂
做传统 CRM 开发的老手都知道，最舒服的状态是所有的字段都能定义好类型：姓名是 varchar，电话是 char，金额是 decimal。但引入 AI 之后，麻烦就来了。
客户和销售在微信、钉钉或者系统内置 IM 里的聊天记录，是非结构化的文本；通话录音是非结构化的音频；甚至客户发来的产品图片、合同扫描件，都是非结构化数据。AI 模型需要消费这些数据，但传统的业务逻辑（比如生成订单、触发审批）又强依赖结构化数据。
如果在数据库设计初期，试图把所有东西都塞进 MySQL 的大字段（Text/JSON）里，后期查询性能会崩得连亲妈都不认识。我们之前的教训就是，为了图省事，把客户标签全存成了一个 JSON 字符串，结果后来想查“过去三个月对价格敏感且有过投诉记录”的客户，一个 SQL 下去，数据库 CPU 直接飙到 100%。
所以，智能 AI CRM 的数据库设计，第一条原则就是：混合存储，各司其职。
二、基础架构：关系型数据库的“瘦身”与“拆分”
在 AI-CRM 里，MySQL（或者 PostgreSQL）依然不可替代，它是真理来源（Source of Truth）。但是，它的表结构必须“瘦身”。
1. 客户主表（t_customer_base）
这张表只存最核心、变更频率低的数据。
CREATE TABLE t_customer_base (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
customer_code VARCHAR(64) UNIQUE NOT NULL, -- 业务唯一码
name VARCHAR(128) NOT NULL,
source_type TINYINT DEFAULT 1, -- 来源：1 官网 2 导入 3 广告
owner_id BIGINT NOT NULL, -- 归属销售
status TINYINT DEFAULT 1, -- 1 潜在 2 成交 3 流失
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
INDEX idx_owner_status (owner_id, status),
INDEX idx_code (customer_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
注意看，这里没有放“行业”、“规模”、“偏好”这些字段。为什么？因为这些是动态的，是 AI 随时可能修正的。如果把这些频繁更新的字段放在主表，会导致行锁竞争加剧，尤其是在高并发写入日志的时候。
2. 动态属性表（t_customer_attributes）
我们将动态标签和属性剥离出来，采用 EAV（Entity-Attribute-Value）模型的变种，或者直接利用 PostgreSQL 的 JSONB 特性。考虑到国内大部分团队还是用 MySQL，我们采用“主表 + 扩展表”的模式。
CREATE TABLE t_customer_attributes (
customer_id BIGINT PRIMARY KEY,
industry_tag VARCHAR(64), -- 行业
scale_tag VARCHAR(64), -- 规模
ai_risk_level TINYINT, -- AI 计算的风险等级
ai_intent_score DECIMAL(5,2), -- AI 意图评分
last_interaction_summary TEXT, -- 最近一次交互摘要（由 AI 生成）
raw_data_snapshot JSON, -- 原始数据快照，用于回溯
version INT DEFAULT 1, -- 乐观锁版本号
INDEX idx_risk (ai_risk_level),
INDEX idx_score (ai_intent_score)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
这里有个细节，raw_data_snapshot 存的是 JSON。这不是为了省表，而是为了当 AI 模型迭代后，我们可以用新的模型重新跑旧数据，而不需要去翻原始的日志表。这个字段是连接“过去”和“未来”的桥梁。
3. 交互日志表（t_interaction_log）
这是整个系统里数据量增长最快的表。每一次通话、每一条消息、每一次邮件，都要记在这里。这张表的设计直接决定了系统的写入性能。
千万别在这张表里做复杂的外键关联。我们甚至建议按时间分表，或者直接使用 TiDB 这类分布式数据库。
CREATE TABLE t_interaction_log (
id BIGINT PRIMARY KEY, -- 雪花算法生成
customer_id BIGINT NOT NULL,
user_id BIGINT NOT NULL, -- 操作人员或系统账号
channel_type TINYINT, -- 1 电话 2 微信 3 邮件 4 系统
content_type TINYINT, -- 1 文本 2 语音 3 文件
content_text TEXT, -- 文本内容或语音转写文本
file_url VARCHAR(512), -- 文件存储地址
direction TINYINT, -- 1 呼入 2 呼出
occur_time DATETIME NOT NULL,
ai_processed TINYINT DEFAULT 0, -- 是否已被 AI 处理
vector_id VARCHAR(128), -- 关联向量库的 ID
INDEX idx_customer_time (customer_id, occur_time),
INDEX idx_process_status (ai_processed, occur_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
注意 ai_processed 和 vector_id 这两个字段。这是传统 CRM 里没有的。它们标志着这条数据已经进入了 AI 的处理流水线。vector_id 尤其重要，它是关系型数据库和向量数据库之间的“指针”。
三、核心引擎：向量数据库的引入与融合
如果说 MySQL 是 CRM 的骨架，那向量数据库（Vector DB）就是 AI-CRM 的大脑。没有它，所谓的“智能”只能停留在关键词匹配的低级阶段。
在结构设计上，我们不能把向量数据库当成一个黑盒，它必须深度集成到业务流中。目前主流的选型有 Milvus、Weaviate，或者直接用 PostgreSQL 的 pgvector 插件。为了降低运维复杂度，如果数据量在千万级以内，我强烈建议先用 pgvector，架构最简单。如果数据量上亿，再考虑独立的 Milvus 集群。
1. 向量集合设计（Collection Design）
在向量库里，我们通常建立两个核心集合（Collection）：customer_profile_vectors 和 interaction_vectors。
customer_profile_vectors 存的是客户画像的嵌入向量。比如，把客户的历史购买记录、浏览行为、基础标签通过一个 Embedding 模型转化成一个 768 维的向量。这个向量代表的是“这个客户是谁”。
interaction_vectors 存的是每一次交互内容的语义向量。比如销售问“您预算多少”，客户回“大概 50 万左右”，这句话会被转化成向量存起来。这个向量代表的是“发生了什么”。
2. 数据一致性挑战
这里有个巨大的坑：当 MySQL 里的客户数据更新了，向量库里的向量怎么同步？
绝对不能依赖应用层的代码去双重写入。一旦代码逻辑有漏洞，或者网络抖动，两边数据就不一致了。到时候销售在界面上看到客户是 A 类，AI 推荐策略却是按 B 类给的，这就出事故了。
我们的解决方案是引入 CDC（Change Data Capture）机制，比如使用 Canal 监听 MySQL 的 Binlog。
MySQL (Binlog) -> Kafka -> Flink/ETL -> Vector DB
当 t_customer_attributes 表发生更新时，CDC 工具捕获变更，发送到消息队列。后端有一个专门的同步服务消费这个消息，调用 Embedding 模型重新生成向量，然后更新到向量库中。
在数据库结构设计文档里，必须明确标注这个异步链路。对于实时性要求极高的场景（比如销售正在聊天，需要实时推荐话术），我们允许短暂的延迟（最终一致性），但在 t_interaction_log 里要标记 vector_sync_status，确保运维人员能监控到哪些数据还没向量化。
四、AI 特征仓库：为模型训练做准备
很多团队做 CRM，只想着怎么查数据，忘了怎么“喂”数据给模型。智能 CRM 的数据库设计，必须包含一个“特征仓库”的概念。
模型训练需要的是宽表，是历史时间切片的数据。直接查业务库是禁忌，会拖垮线上服务。我们需要设计一套中间层结构，通常称为 t_ai_feature_store。
这张表不需要支持高频更新，但需要支持高效的批量读取。结构上，它应该是以“客户 + 时间窗口”为粒度的。
CREATE TABLE t_ai_feature_store (
id BIGINT PRIMARY KEY,
customer_id BIGINT NOT NULL,
window_date DATE NOT NULL, -- 数据所属日期
feature_version VARCHAR(32), -- 特征版本，用于模型迭代
total_order_amount DECIMAL(18,2), -- 历史总订单
avg_response_time INT, -- 平均回复时长（秒）
complaint_count_30d INT, -- 近 30 天投诉次数
sentiment_score_avg DECIMAL(5,2), -- 平均情感得分
last_login_days INT, -- 距上次登录天数
-- 这里可以预留几十个甚至上百个特征字段
-- 或者使用列式存储格式
raw_features JSON,
created_at DATETIME
) ENGINE=InnoDB;
设计这张表的难点在于特征的计算逻辑。是每天凌晨跑批？还是实时计算？在数据库层面，我们建议采用“分层计算”。基础统计类（如订单总额）通过数据库视图或定时任务生成；复杂语义类（如情感得分）通过流式计算写入。
在表结构里保留 feature_version 至关重要。因为 AI 模型会迭代，V1 模型用的特征和 V2 模型用的特征可能不一样。如果数据库结构写死了，模型升级就得改表结构，这是运维灾难。用 JSON 或者预留足够的列，配合版本号管理，能让我们在不停机的情况下切换模型。
五、性能优化：索引、分片与缓存
到了实战阶段，理论设计得再好，扛不住并发也是白搭。智能 CRM 有个特点：读多写多，且查询条件极其复杂。销售可能想查“北京地区、最近一周有过互动、AI 评分高于 80 分、且未成交”的客户。
1. 索引策略
在 MySQL 中，针对 t_customer_attributes 表，不要试图给所有字段都建索引。AI 评分（ai_intent_score）是一个范围查询，适合建索引；但如果是多条件组合，单列索引效果有限。
我们采用了“覆盖索引”的策略。比如，列表页只需要展示客户名、分数、状态。那就建立一个联合索引 idx_list_view (status, ai_intent_score, id)，这样查询可以直接从索引树拿数据，不用回表。
对于向量检索，索引机制完全不同。Milvus 或 pgvector 使用的是 HNSW 或 IVF 索引。在结构设计时，要规划好 nlist 和 m 参数。数据量在 100 万以内，HNSW 查询最快；超过 1000 万，IVF_PQ 更省内存。这些参数虽然不属于 SQL 表结构，但属于“数据库逻辑设计”的一部分，必须写进文档里。
2. 读写分离与缓存
AI 计算是耗时的。当销售打开客户详情页时，系统需要展示 AI 生成的“下一步建议”。这个建议不可能每次实时算，太慢了。
我们在 Redis 里设计了一个缓存结构：crm:ai:suggestion:{customer_id}。有效期设为 30 分钟。数据库结构里要配合一个 suggestion_update_time 字段。
查询逻辑是：先查 Redis，有则返回；无则查 DB 触发异步计算，并返回旧数据或默认数据。这里有个细节，当 t_interaction_log 有新数据写入时，要通过消息队列通知缓存服务，删除对应的 Redis 键，保证数据的相对新鲜度。
3. 历史数据归档
CRM 系统用个两年，日志表轻松破亿。查询变慢是必然的。我们设计了冷热分离机制。
t_interaction_log 只保留最近 6 个月的热数据。6 个月前的数据，通过 ETL 任务迁移到 t_interaction_log_history 表，甚至直接导出到 ClickHouse 或 Elasticsearch 做离线分析。
在应用层的数据库连接配置里，要区分“热库”和“冷库”。销售日常操作走热库，报表统计走冷库。表结构设计时，历史表可以省略一些非必要的索引，以节省存储空间。
六、安全与合规：数据库设计的底线
现在做 CRM，不考虑隐私合规就是裸奔。尤其是引入了 AI，数据泄露的风险更大。数据库结构设计必须把安全考虑进去。
1. 字段级加密
客户的手机号、身份证、银行卡号，绝对不能明文存储。我们在 t_customer_base 里设计了 phone_cipher 字段，存储加密后的密文。同时，为了支持搜索（比如销售通过手机号找客户），我们引入了“盲索引”机制。
CREATE TABLE t_customer_base (
...
phone_cipher VARBINARY(256) NOT NULL, -- 加密手机号
phone_hash CHAR(64) NOT NULL, -- 手机号的 HMAC 哈希，用于搜索
...
INDEX idx_phone_hash (phone_hash)
);
搜索时，系统先对输入的手机号计算 HMAC 哈希，然后查 phone_hash 字段，找到记录后再解密 phone_cipher。这样即使数据库被拖库，攻击者拿到的也只是一堆乱码和无法反推的哈希值。
2. 数据权限隔离
B 端系统最复杂的就是数据权限。不同级别的销售，能看到的数据范围不一样。在数据库层面，我们不建议把权限逻辑硬编码在 SQL 里（比如每个查询都 AND org_id = ?）。
我们设计了一张 t_data_scope 表，定义每个角色的数据可见范围。在 ORM 层或中间件层自动注入过滤条件。但在表结构上，每张业务表都必须包含 org_id（组织 ID）和 owner_id（拥有者 ID），这是物理隔离的基础。
3. 审计日志
谁在什么时候查看了什么客户数据？这个必须记录。我们单独设计了一个 t_audit_log 库，甚至部署在独立的物理实例上，防止被主库管理员篡改。
CREATE TABLE t_audit_log (
id BIGINT PRIMARY KEY,
operator_id BIGINT,
action_type VARCHAR(32), -- VIEW, EXPORT, EDIT
target_table VARCHAR(64),
target_id BIGINT,
request_ip VARCHAR(45),
occur_time DATETIME,
risk_level TINYINT -- 由 AI 实时判断的操作风险
);
注意 risk_level 字段。这是 AI 介入安全的一个点。如果某个账号短时间内大量导出客户数据，AI 模型会识别为异常行为，将 risk_level 标红，触发告警。这个字段是数据库与风控系统交互的接口。
七、总结与演进思考
写到这，大概把智能 AI CRM 数据库设计的骨架搭出来了。回顾一下，核心变化在于三点：
第一，从“存结果”到“存过程”。传统 CRM 存客户状态，AI CRM 存交互日志和向量，因为过程里藏着意图。 第二，从“单一存储”到“混合架构”。MySQL 管事务，Vector DB 管语义，Redis 管速度，ClickHouse 管分析。数据库设计不再是画 ER 图，而是设计数据流转的管道。 第三，从“被动记录”到“主动计算”。特征表、向量索引、异步同步链路，这些都是为了让数据能随时被模型消费。
当然，这套结构也不是银弹。在实际落地中，最大的挑战往往不是技术，而是业务变更。今天 AI 模型需要这个特征，明天产品经理又说要加那个维度。所以，数据库设计一定要留有余地。JSON 字段该用就用，垂直分表该做就做，别为了所谓的“范式”把扩展性锁死。
最后想说的是，技术是为业务服务的。如果企业连基础的客户数据都录不全，录入的数据全是错的，那搞再复杂的向量数据库、再精妙的特征工程，跑出来的 AI 建议也是垃圾。数据库结构设计只是地基，数据治理和质量控制才是上面的大楼。
这套方案是我们团队在经历了两次重构、处理了数亿条交互数据后沉淀下来的。它不一定适合所有公司，初创团队可能一个 PostgreSQL 就够了，但对于想要真正落地 AI 能力的中大型 CRM 系统，这种混合架构是必经之路。希望这些实战中的细节，能帮正在踩坑的你省点时间。毕竟，在数据库上炸一次库，通宵事小，丢数据事大。
△悟空AI CRM产品截图
推荐立刻免费使用中国著名AI CRM品牌-悟空AI CRM，显著提升企业运营效率，相关链接：
AI CRM系统免费试用
AI CRM系统介绍