核心结论：用宽表 + 时间分区 + 索引组合，比星型模型更适配简易分析系统
如果你的数据量在千万级以内、查询以“按天/按用户/按事件类型聚合”为主、且不涉及多维下钻或复杂关联，
单张宽表配合合理索引和分区，比强行套用
star schema（星型模型）更轻量、更易维护、查询也更快。
为什么不用标准星型模型？
星型模型适合 OLAP 场景下的复杂分析，但简易系统往往卡在三个现实问题上：
事实表和
维度表之间频繁
JOIN，MySQL 在无足够内存或不当索引时，
JOIN成为性能瓶颈 维度表如
user_dim或
product_dim需要定期
UPDATE或
SLOW INSERT，而简易系统通常只追加数据 业务变化快（比如新增一个埋点字段），星型模型要改多张表+ETL逻辑；宽表只需加一列+调整索引
推荐宽表结构与关键字段设计
以用户行为分析为例，一张
event_log表覆盖 80% 查询需求：
CREATE TABLE `event_log` (
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`event_time` DATETIME NOT NULL,
`date_key` DATE NOT NULL COMMENT '用于分区和快速日期过滤',
`user_id` VARCHAR(64) NOT NULL,
`event_type` VARCHAR(32) NOT NULL,
`page_path` VARCHAR(255) DEFAULT NULL,
`referral` VARCHAR(255) DEFAULT NULL,
`utm_source` VARCHAR(64) DEFAULT NULL,
`device_type` ENUM('mobile','desktop','tablet') DEFAULT 'desktop',
`country` CHAR(2) DEFAULT NULL,
`duration_sec` INT UNSIGNED DEFAULT NULL,
`is_new_user` TINYINT(1) DEFAULT 0,
PRIMARY KEY (`id`, `date_key`),
KEY `idx_date_event` (`date_key`, `event_type`),
KEY `idx_user_date` (`user_id`, `date_key`),
KEY `idx_event_time` (`event_time`),
KEY `idx_utm_source` (`utm_source`)
) ENGINE=InnoDB
PARTITION BY RANGE (TO_DAYS(`date_key`)) (
PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),
PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),
PARTITION p202403 VALUES LESS THAN (TO_DAYS('2024-04-01')),
PARTITION p_future VALUES LESS THAN MAXVALUE
);
说明：
date_key是冗余字段，必须与
event_time保持一致（写入时由应用层或触发器保证），它是分区键和高频查询条件 主键设为
(id, date_key)，既支持自增，又让分区裁剪生效；避免用
event_time做主键第一列（精度高、范围大、B+树分裂频繁） 分区按月切分，
TO_DAYS()比直接用
DATE更稳定（避免某些 MySQL 版本对
DATE分区的隐式转换问题）
ENUM字段如
device_type比
VARCHAR节省空间且查得快，但别超过 5–6 个固定值，否则维护成本上升
查询优化与常见陷阱
多数慢查询不是因为 SQL 写错，而是没绕开 MySQL 的执行限制：
避免在WHERE中对
date_key做函数操作，例如
WHERE DATE(event_time) = '2024-03-15'会跳过分区和索引；应写成
WHERE date_key = '2024-03-15'聚合统计时，
GROUP BY user_id若结果集超百万行，即使有索引也容易触发
Using temporary; Using filesort；可先用
WHERE date_key BETWEEN ...缩小范围再聚合
SELECT COUNT(*) FROM event_log WHERE date_key = '2024-03-01'在大分区下仍可能慢——确认是否启用了
innodb_stats_persistent，并定期运行
ANALYZE TABLE event_log不要在宽表里存 JSON 字段做“灵活扩展”，MySQL 对 JSON 字段的索引支持有限（5.7+ 支持生成列索引，但写法繁琐、易出错）；真需要灵活字段，单独建一张
event_attr宽度可控的附表更稳妥
真正难的是数据写入一致性（比如
date_key和
event_time同步）、分区维护脚本的健壮性，以及随着字段增多，
ALTER TABLE ADD COLUMN在大表上的锁表现——这些细节比表结构本身更决定系统能否长期跑稳。
