PostgreSQL与MySQL在SaaS客服系统中的选型实践

1. 项目背景与需求分析

去年夏天，当我决定为自己的SaaS产品开发一套独立的在线客服系统时，数据库选型成了第一个需要攻克的难题。市面上成熟的客服系统大多采用MySQL作为默认存储方案，但作为一个长期使用PostgreSQL的老兵，我始终认为PostgreSQL的特性（如JSONB、全文检索、更丰富的索引类型）可能更适合处理客服场景中的非结构化数据和复杂查询。

这个项目的核心目标很明确：构建一个支持多租户、高并发的在线客服系统，需要处理三种主要数据类型：

• 结构化的用户/客服账号信息
• 半结构化的对话记录（含元数据）
• 完全非结构化的附件/富媒体内容

最初版本基于MySQL 8.0开发，但在处理以下场景时遇到了明显瓶颈：

1. 单条对话记录可能包含嵌套的JSON（用户自定义字段、表情反应、阅读状态等）
2. 需要实时统计客服响应时间的百分位数（P95/P99）
3. 多租户场景下的数据隔离与跨租户聚合查询

2. 技术方案选型对比

2.1 PostgreSQL的核心优势验证

在评估PostgreSQL的适用性时，我重点测试了以下特性在实际客服场景中的表现：

JSONB与索引组合

sql复制-- 创建包含JSONB字段的对话表
CREATE TABLE conversations (
    id BIGSERIAL PRIMARY KEY,
    tenant_id INT NOT NULL,
    channel_id INT NOT NULL,
    participants JSONB NOT NULL,  -- 包含用户/客服ID数组
    metadata JSONB,  -- 设备信息、IP等
    tags JSONB[],    -- 多维标签
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- 为JSONB字段创建GIN索引
CREATE INDEX idx_conversations_metadata ON conversations USING GIN (metadata);
CREATE INDEX idx_conversations_tags ON conversations USING GIN (tags);

实测发现，对于包含10万条记录的对话表，带JSONB条件的查询速度比MySQL的JSON类型快3-5倍，特别是在使用@>操作符进行包含查询时：

sql复制-- 查找使用iOS设备的客户对话
SELECT * FROM conversations 
WHERE metadata @> '{"device": "iPhone"}';

窗口函数实现响应时间分析

sql复制-- 计算每个客服的P95响应时间
WITH response_stats AS (
    SELECT
        staff_id,
        EXTRACT(EPOCH FROM (response_time - create_time)) AS delay_seconds,
        PERCENT_RANK() OVER (PARTITION BY staff_id ORDER BY EXTRACT(EPOCH FROM (response_time - create_time))) AS percentile
    FROM messages
    WHERE response_time IS NOT NULL
)
SELECT 
    staff_id,
    AVG(CASE WHEN percentile <= 0.95 THEN delay_seconds END) AS p95_response
FROM response_stats
GROUP BY staff_id;

2.2 MySQL的适用场景保留

尽管PostgreSQL在复杂查询上表现优异，但MySQL在以下场景仍具优势：

1. 简单CRUD操作的吞吐量：在纯键值查询场景下，MySQL的QPS比PostgreSQL高约15-20%
2. 云服务兼容性：多数PaaS服务对MySQL的支持更成熟（如Vitess分片）
3. 开发工具生态：ORM框架对MySQL的适配通常更全面

因此最终架构采用了混合模式：

• 核心业务数据（用户、工单）保留在MySQL
• 对话记录、统计报表迁移到PostgreSQL
• 通过Debezium实现两者间的CDC同步

3. 具体实现细节

3.1 多租户数据隔离方案

PostgreSQL实现方案

sql复制-- 使用Row-Level Security (RLS)
CREATE POLICY tenant_isolation_policy ON conversations
    USING (tenant_id = current_setting('app.current_tenant')::INT);

ALTER TABLE conversations ENABLE ROW LEVEL SECURITY;

对比MySQL的实现

sql复制-- 需要在每个查询显式添加tenant_id条件
SELECT * FROM conversations WHERE tenant_id = ?;

实测发现PostgreSQL的RLS方案：

• 开发效率提升：无需手动维护tenant_id条件
• 安全性更强：防止误操作泄露跨租户数据
• 性能损耗：约3-5%的查询开销

3.2 对话全文检索实现

PostgreSQL方案

sql复制-- 创建全文搜索配置
CREATE TEXT SEARCH CONFIGURATION chinese_simple (COPY = simple);
ALTER TEXT SEARCH CONFIGURATION chinese_simple 
    ALTER MAPPING FOR hword, hword_part, word 
    WITH pg_catalog.english_stem;

-- 添加搜索列
ALTER TABLE messages ADD COLUMN search_vector tsvector;
UPDATE messages SET search_vector = 
    to_tsvector('chinese_simple', coalesce(content,''));

-- 创建GIN索引
CREATE INDEX idx_messages_search ON messages USING GIN(search_vector);

MySQL方案对比

sql复制-- 使用内置全文索引
ALTER TABLE messages ADD FULLTEXT INDEX idx_content (content);

性能测试结果（100万条消息）：

3.3 实时统计看板实现

利用PostgreSQL的物化视图和窗口函数：

sql复制-- 创建实时统计的物化视图
CREATE MATERIALIZED VIEW stats_dashboard AS
WITH 
-- 各渠道对话数
channel_stats AS (...),
-- 客服响应时间
response_stats AS (...)
SELECT * FROM channel_stats 
FULL OUTER JOIN response_stats ON ...;

-- 定时刷新（可通过pg_cron扩展实现自动化）
REFRESH MATERIALIZED VIEW CONCURRENTLY stats_dashboard;

同等功能在MySQL中需要：

1. 创建多个汇总表
2. 依赖应用层定时任务更新
3. 无法保证查询时的数据一致性

4. 性能优化实战记录

4.1 PostgreSQL特定调优

连接池配置

ini复制# postgresql.conf关键参数
max_connections = 200
shared_buffers = 4GB              # 25% of total RAM
effective_cache_size = 12GB       # 75% of total RAM
maintenance_work_mem = 1GB
work_mem = 32MB                   # 每个查询操作可用内存
random_page_cost = 1.1            # SSD存储建议值

索引优化技巧

sql复制-- 对时间范围查询使用BRIN索引
CREATE INDEX idx_conversations_created_at ON conversations 
USING BRIN (created_at) WITH (pages_per_range = 32);

-- 对多条件查询使用复合索引
CREATE INDEX idx_messages_composite ON messages 
(tenant_id, channel_id, created_at) 
INCLUDE (status);

4.2 MySQL对比配置

ini复制# my.cnf关键参数
innodb_buffer_pool_size = 12G     # 70% of total RAM
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2
innodb_read_io_threads = 16
innodb_write_io_threads = 16

5. 踩坑与经验总结

5.1 PostgreSQL特有陷阱

JSONB更新性能问题

sql复制-- 反模式：全量更新整个JSONB字段
UPDATE conversations SET metadata = '{"new": "value"}' WHERE id = 1;

-- 正确做法：使用jsonb_set函数局部更新
UPDATE conversations 
SET metadata = jsonb_set(metadata, '{new}', '"value"') 
WHERE id = 1;

事务ID耗尽风险

sql复制-- 监控事务ID使用情况
SELECT 
    100 * (txid_current() % 2147483646) / 2147483646 AS txid_used_percent;

5.2 混合架构下的同步挑战

使用Debezium时需要注意：

1. 模式变更处理：PostgreSQL的DDL变更需要手动同步到MySQL
2. 时区问题：两种数据库的TIMESTAMP处理方式不同
3. 连接器内存配置：处理大事务时需要调整max.queue.size

6. 最终架构与性能指标

上线三个月后的生产环境数据：

迁移过程中的关键发现：

1. PostgreSQL的并行查询对分析型操作提升显著
2. JSONB的局部更新比预期更消耗WAL日志空间
3. RLS策略对JOIN查询的性能影响需要特别关注