4. 商户数据模型设计：核心表结构与索引优化

在高并发评分场景下，数据模型是吞吐量与准确性的基石。本章围绕商户风险评分所需的五张核心表，从字段设计、分表策略到索引优化进行系统性讲解，确保模型在千万级商户、亿级流水下仍能保持毫秒级响应。

4.1 商户基础信息表（merchant_base）

该表存储商户静态属性，写入低频、读取高频，是评分引擎的“字典”。

4.2 交易流水表（transaction_flow）

交易流水是评分计算的核心数据源，写入量极大（日均千万～亿级），需按时间维度分表。

• 分表策略：按 trans_date 做 RANGE 分区，每月一张物理表（transaction_flow_202501）。
• 写入优化：使用批量 INSERT（每批 500～1000 行），关闭二级索引实时维护（先入表后建索引或使用在线 DDL）。
• 查询模式：按商户 ID + 时间范围查询，避免全表扫描。

-- 推荐索引：覆盖评分引擎最频繁的查询
ALTER TABLE transaction_flow_202501 ADD INDEX idx_merchant_time (merchant_id, trans_time);
ALTER TABLE transaction_flow_202501 ADD INDEX idx_device (device_fingerprint);

4.3 风险事件表（risk_event）

记录商户触发的各类风控事件（如频繁退款、异地登录、大额异常），用于特征衍生与历史回溯。

• 写入特点：事件驱动写入，单次写入量小但并发高。
• 保留周期：事件数据保留 180 天，超期归档至冷存储（如 HBase/OSS）。
• 查询特点：按商户 ID 查询近期事件列表，用于实时评分特征计算。

-- 核心索引：按商户查询近期事件
ALTER TABLE risk_event ADD INDEX idx_merchant_type_time (merchant_id, event_type, event_time);

4.4 黑白名单表（risk_list）

黑白名单用于快速拦截或放行，要求极低延迟（< 5ms），通常结合缓存使用。

• 存储策略：MySQL 作为持久化层 + Redis 作为缓存层（TTL 3600s）。
• 名单类型：商户级黑名单、设备级黑名单、IP 级黑名单。
• 过期机制：名单可设置过期时间，过期后自动失效。

-- 唯一索引：防止重复名单
ALTER TABLE risk_list ADD UNIQUE INDEX uk_target (list_type, target_type, target_value);

4.5 评分结果表（risk_score_result）

存储每次评分计算的输出结果，用于报表、监控与人工审核。

• 写入频率：每次评分请求写入一条记录，写入量 = 评分 QPS。
• 查询模式：按商户 ID 查询最新评分结果，或按时间范围拉取评分趋势。
• 数据保留：保留 90 天，超期归档至分析型数据库（如 ClickHouse）。

-- 覆盖索引：查询商户最新评分
ALTER TABLE risk_score_result ADD INDEX idx_merchant_score_time (merchant_id, score_time DESC);

4.6 数据模型整体架构图

下图展示了五张核心表之间的关联关系与数据流向，帮助理解评分引擎如何串联各表数据。

4.7 索引优化核心原则

在高并发场景下，索引设计直接决定数据库吞吐能力。以下是必须遵守的优化原则：

1. 覆盖索引优先：让索引包含查询所需的所有字段，避免回表。例如 idx_merchant_time 覆盖商户 ID + 时间范围查询。
2. 联合索引最左匹配：将区分度最高的字段放在最左侧。商户 ID 作为查询入口，始终放在联合索引第一位。
3. 避免冗余索引：删除长期未被使用的索引，减少写入开销。可通过 performance_schema 或慢查询日志分析。
4. 索引下推（ICP）：MySQL 5.6+ 自动启用，联合索引中无法完全匹配的查询条件会在存储引擎层过滤，减少回表行数。
5. 分区裁剪：交易流水表按时间分区后，查询语句必须带上时间条件，让优化器直接裁剪无关分区。

4.8 分库分表策略

当单表数据量超过 5000 万行或写入 QPS 超过 1 万时，必须引入分库分表。推荐策略如下：