1. 架构目标与核心指标
1.1 高吞吐与低延迟的关系
在<电商场景中，推荐系统需要在<高速写入与<强>低延迟查询之间取得平衡，核心指标包含 吞吐量、延迟、可用性以及数据的新鲜度。合理的表结构应当让新增行为能够快速落库，同时让后续的推荐计算能够实时或近实时读取到最新数据。
为了实现这一目标，通常采用写入优先的表设计与查询友好的索引结构，同时通过分区与分表把热数据与冷数据分离，降低单表的热度与锁竞争。这些设计直接影响推荐系统的刷新周期与在线体验。
1.2 数据生命周期与分区策略
数据会经历热数据、温数据与冷数据的生命周期，热数据保留在近实时需要的范围，冷数据则可以通过分区下沉或归档处理。借助按日期分区的策略，可以实现对历史数据的高效管理，而在SQL查询中也能通过分区裁剪快速定位需要的记录集。
在设计上，应该使用按时间维度分区和<适度的分区数量来避免分区管理成为瓶颈，同时结合归档策略将超过保留期限的数据移出热路径，保持高吞吐与低延迟的同时提升可维护性。
2. 面向电商场景的表结构设计原则
2.1 以写入为核心的表设计
在高并发写入的环境下，外键约束应尽量在数据库级禁用或尽量避免，以减少写入时的锁开销与二次查询成本。宽表/窄表取舍要以写入速率和后续查询模式为依据，优先考虑简单的、可扩展的字段集合，避免过度规范化带来的复杂联表查询。
同时，字段类型应统一且紧凑，减少行宽和IO消耗；将常用的主键设计为 BIGINT/UNSIGNED，对频繁筛选的字段建立覆盖索引，以降低回表成本。
2.2 以查询为导向的索引策略
推荐系统的查询模式往往围绕用户、时间、以及商品的最近行为，因此应构建符合查询路径的复合索引与适当的列选取，实现覆盖查询或最小化的回表。对于热数据，优先让热点字段落在聚簇索引前列，以提升范围查询与排序的性能。
同时要考虑分区裁剪的可视性，在分区中创建局部索引，减少跨分区的检索成本。对于写入频繁但查询较简单的场景，可以使用单列索引与日常的批量写入相结合的策略。
3. 核心表与字段设计范式
3.1 事件事实表（UserEvent）
事件事实表承担高吞吐写入的核心任务，字段设计要确保追加写入的高效性，以及对推荐模型的实时特征提取友好。常见字段包括 id、user_id、item_id、action_type、ts，以及必要的 上下文信息。主键自增有助于写入吞吐，同时避免复杂的唯一性约束带来的开销。
CREATE TABLE user_event (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL,
item_id BIGINT UNSIGNED NOT NULL,
action_type TINYINT NOT NULL, -- 0:view, 1:click, 2:add_to_cart, 3:purchase
ts DATETIME NOT NULL,
platform VARCHAR(32) NOT NULL,
region VARCHAR(32) NOT NULL,
extra JSON DEFAULT NULL,
PRIMARY KEY (id),
KEY idx_user_item_ts (user_id, item_id, ts),
KEY idx_day_action (DATE(ts), action_type)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC;
在这个设计中，id 作为自增主键，确保写入的高吞吐；user_id、item_id、ts 构成常见查询路径的组合字段，idx_user_item_ts 能快速定位最近行为；extra 字段以 JSON 形式承载扩展上下文，避免频繁变更表结构。
除了事件数据，还需要对热用的特征进行预聚合表，以支持低成本的在线查询与离线特征计算的无缝对接。
CREATE TABLE user_event_daily_summary (
user_id BIGINT UNSIGNED NOT NULL,
day DATE NOT NULL,
total_views INT UNSIGNED NOT NULL DEFAULT 0,
total_clicks INT UNSIGNED NOT NULL DEFAULT 0,
total_purchases INT UNSIGNED NOT NULL DEFAULT 0,
last_ts DATETIME NOT NULL,
PRIMARY KEY (user_id, day)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC;
3.2 维度表设计（User、Item、Time）
维度表用于降低查找成本并提供可复用的描述性信息。去外键化的策略在高吞吐场景中更有利，因为跨表联接会增加锁与IO消耗；维度数据通常以定期批处理方式加载，并通过内存表或缓存保持快速可用。
典型维度表设计包括：
User：用户基本信息、画像字段、注册时间等；
Item：商品基础信息、分类、品牌、价格区间等；
Time：日期、时间段、工作日/周末等维度，便于离线特征的对齐。
CREATE TABLE dim_user (
user_id BIGINT UNSIGNED NOT NULL,
gender TINYINT NOT NULL,
age_group VARCHAR(16),
region VARCHAR(64),
signup_ts DATETIME,
PRIMARY KEY (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE dim_item (
item_id BIGINT UNSIGNED NOT NULL,
category VARCHAR(64),
brand VARCHAR(64),
price DECIMAL(10,2),
rating FLOAT,
PRIMARY KEY (item_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE dim_time (
day DATE NOT NULL,
day_of_week VARCHAR(16),
is_holiday BOOLEAN,
PRIMARY KEY (day)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
4. 索引、分区和分表策略
4.1 分区设计演练
分区可以把历史数据与活跃数据分开管理，从而提升查询效率与维护性。基于 RANGE COLUMNS(ts) 的分区适用于时间序列数据，便于按日、周、月裁剪。分区策略还应结合 purge/归档计划，确保热数据在高效区间内。
以下示意性分区创建体现了“按日期分区”的思路，实际边界需结合数据规模与保留策略调整。分区裁剪使得查询只扫描相关分区，显著降低 I/O。
ALTER TABLE user_event
PARTITION BY RANGE COLUMNS(ts) (
PARTITION p202401 VALUES LESS THAN ('2024-02-01'),
PARTITION p202402 VALUES LESS THAN ('2024-03-01'),
PARTITION p202403 VALUES LESS THAN ('2024-04-01'),
PARTITION pMax VALUES LESS THAN MAXVALUE
);
在高并发写入下，分区表的并发性高、锁粒度更友好，并能通过删除老分区实现快速归档。同时应留出额外的分区数以应对持续增长的历史数据。
4.2 分表策略与热点分流
对于极高写入量的场景，水平分表（hot tenant/region/item 的分区）有助于消除单表热点。分表后需要在应用层维护跨表查询的一致性与负载均衡，以确保读取压力分散到多台数据库或分区节点。
在设计上，分表常与分区组合使用：主表负责最近数据的写入与查询，历史数据保留在独立的历史分区或历史表中。为了避免冗余数据，可以通过物化视图/聚合表实现对热点数据的快速聚合。
5. 读写分离与缓存协同
5.1 读写分离架构要点
为实现高吞吐，应采用<读写分离架构，把写操作集中在主库，查询工作流走只读副本。这样可以最大化写入带宽，同时提高并发查询的并发度。需要关注的一致性粒度通常是最终一致性或近即时的一致性，而非强一致性。
实现要点包括：连接分流、应用层幂等性处理、以及对副本延迟的监控。对于热数据查询，可以优先路由到某些高性能只读副本，以减少主库压力。
5.2 缓存与数据库特性结合
缓存系统（如 Redis）在推荐系统中用于保存最近行为的聚合结果、热特征以及热点商品。Cache-Aside 模型常与 MySQL 结合使用：应用先查询缓存，缺失时再访问数据库并回填缓存。
将缓存击穿/缓存雪崩等风险降到最小，需要在数据库层做好时间戳和版本控制，并通过一致性哈希与过期策略平衡缓存命中率与数据新鲜度。
-- 示例：最近一天的用户点击聚合查询（伪代码思路）
SELECT user_id, COUNT(*) AS clicks
FROM user_event
WHERE ts >= NOW() - INTERVAL 1 DAY
AND action_type = 1
GROUP BY user_id
ORDER BY clicks DESC
LIMIT 10;
6. 数据一致性与可用性权衡
6.1 幂等性设计与数据幂等性
在高并发写入场景中，幂等性设计是确保数据一致性的关键。通过在应用层实现 唯一请求标识、幂等键映射 与重试控制，可以避免重复写入造成的数据错乱。
数据库层也应尽量减少隐式重复写入的风险，例如通过无自增冲突的分布式唯一键或使用应用侧的分布式锁来控制并发写入路径。这样可以在不牺牲吞吐的前提下提升数据的一致性保障。
6.2 灾备与数据恢复策略
可用性方面，采用主从复制与热备方案，结合定期快照、增量备份以及点时间恢复（PITR）能力。对于分区表，确保备份策略覆盖所有分区以及元数据，以便在灾难发生时快速恢复到最近状态。
此外，数据校验与一致性检查机制应贯穿开发与运维：定期对关键表执行校验、对比离线计算结果与在线聚合结果，确保可观测性与数据质量处于可接受范围内。
