宽表

背景 一张 40 列的宽表，行宽约 1.5KB，单表约 42GB，现有 5 个二级索引。写入画像：INSERT ~600 QPS + 状态 UPDATE ~200 QPS。 现象 一条高频查询（对账明细列表，~300 QPS）： SELEC

背景 我负责一套商户结算系统（MySQL 8.0.32 / InnoDB，单主 16C64G，buffer_pool 32G）。核心表 "t_trade_detail" 约 2800 万行，40 列宽表（大量 VARCHAR(128) 的业

【背景】 热榜上连接池 P99、超时重试、Kafka 位点这些话题，根子往往都落在同一件事上：读路径里到底让数据库在查询时做计算（实时 JOIN / 聚合），还是把结果提前算好、查询时只做取数（宽表 / 物化 / 预聚合）。我做了 10 年

背景 做了 5 年大数据平台，我在不同团队见过同一个问题被讨论至少五次：一张订单表，到底是把商品名、商家名、收货人、支付渠道全冗余进去（宽表），还是只存外键、查询时 JOIN 四张表（窄表）？ 两种做法我都深度参与过。宽表那张 1.2 亿行

背景 做了 10 年大数据平台，最近半年在多个团队里反复看到同一个争论：业务埋点（用户行为日志、操作流水、事件流）到底该怎么建模？我至少碰过三种流派，且每一种背后都站着一位"踩过坑的人"： 1) 扁平宽表派：一张 "events" 大表，几