设计一张百亿级日志表时，分区键、排序键和主键你会怎么选？
我的判断
百亿日志表通常按月或天分区管理生命周期，排序键围绕高频过滤顺序设计，不能把高基数用户直接做分区。
我会先拿 Top 查询和保留策略。每天几百 GB、保留半年时可以按天或月分区：删除旧数据直接 drop partition，也避免分区过多。把 user_id 作为分区会产生海量小分区和 Part，运维会先崩。
排序键决定 Part 内物理顺序。若查询总是租户 + 时间，再按服务或用户过滤，可以设计：
PARTITION BY toYYYYMM(event_time)
ORDER BY (tenant_id, service, event_date, event_time, trace_id)
低基数且高频等值条件放前面，时间字段保证范围裁剪；高基数 traceId 放后，避免点查之外的查询失去前缀。Primary key 可以是 ORDER BY 的前缀以控制索引大小。
我会用真实查询回放比较 marks 命中、read_rows、压缩率和写入排序成本。排序键一旦选错，后续变更通常需要重写数据，不能只凭字段选择性拍板。