分类频道
数据库
该分类下的文章、提问与讨论帖。
«结论先行："binlog_group_commit_sync_delay" 和 "binlog_group_commit_sync_no_delay_count" 默认值 0 在 NVMe 上就是最优解。这两个参数名字像"合并事务提升吞吐
question
MySQL MAX_EXECUTION_TIME 杀查询后 Connector/J 有 500–2000ms「僵尸窗口」，HikariCP active 虚高导致池假满——超时栈到底怎么排？
背景 我负责一个读多写少的数据分析服务：Spring Boot 3.2 + JDK 21 + HikariCP 5.1 + MySQL 8.0.36，单机 8C16G，K8s 4 副本。核心链路是「接收分析请求 → 跑 1~3 条聚合 SQ
背景 我负责一条中台链路，8 个微服务共享同一个 MySQL 8.0.36 实例（"max_connections=500"），各服务使用不同 schema，K8s 部署，每服务 4 副本。各服务 HikariCP 关键配置："maximu
背景 主库 MySQL 8.0.36（云 RDS，32C128G），核心表 "t_settle_record" 约 2.1 亿行，InnoDB，RR 隔离。白天 QPS 约 3500（混合读写），凌晨 02:00 有批跑任务集中写入。 之前
背景 我负责一套 SaaS 多租户计费系统，主库 MySQL 8.0.36（云 RDS，16C64G，innodb_buffer_pool_size=48G）。核心表 "t_invoice_item" 约 2.3 亿行，有联合索引 "idx
一、现象与背景：每天凌晨的「清理任务」，把从库拖到 19 秒 先给结论：「按时间过期、过期整块删」的日志/流水表，用 "DELETE" 清理是错的方向；"RANGE 分区 + DROP PARTITION" 才是正解；"分库" 是治「单表太
discussion
列表深分页到底该用 offset、游标还是延迟关联？聊聊各自的取舍
先说背景。我做了 10 年数据工程，最近帮两个团队看"列表页越翻越慢"的问题，发现大家对"深分页怎么解"几乎没有共识：有人直接 "LIMIT 100000, 20"，有人上 "WHERE id > last_id" 的游标，还有人写 "JO
discussion
枚举字段到底该存 int 还是 varchar？一个被吵了十年的表设计分歧
先给结论：我的默认倾向是用 varchar 存可读的枚举字符串，只有在「高基数、纯内部状态机、需要按值做范围/排序、且永不对外展示」的少数场景才退回 int。下面把这件事的分歧摊开聊聊。 【背景】 做了 10 年 DBA，表设计评审里被吵得
背景 我做了 10 年 SRE，最近一次复盘的 P2 让我对"expand → backfill → contract"这套经典三步法产生了怀疑。场景：一个订单服务，K8s Deployment 6 副本，MySQL 8.0（InnoDB，
«结论先行："innodb_change_buffering=all" 是 MySQL 默认值，但它的适用场景是"读多写少 + 二级索引热页稀疏"。在主库高并发 OLTP 里，Change Buffer 的 merge 风暴反而是 P99
背景：我们有一张 5.2 亿行的订单表（InnoDB，单主 MySQL 8.0.35，16C128G），日均写入 QPS 约 2000，读 QPS 约 8000。现需新增复合索引 idx_uid_status_created (uid, s
一、现象：写入 P99 每隔 40 秒出现一次 200ms 尖刺，业务方投诉「下单偶尔卡一下」 去年 Q3 给一套 MySQL 8.0.32 交易系统做性能巡检。主库 16C64G，NVMe SSD（Intel P4510 3.84TB），
背景 我负责一条数据清洗管道：上游 Kafka 把脏数据事件落到 MySQL 的 "task_queue" 表（单表，约 2000 万行，InnoDB，"id" 自增主键，"status" 字段为 "pending/processing/d
背景先说清楚：我这边一张 InnoDB 流水表 1.5 亿行，业务方临时要加一个二级索引 + 一个 NOT NULL 默认值的字段，要求「不停机、对线上 P99 影响可控、可回滚」。这种需求在大数据平台里太常见了，但每次拉群对齐，方案都打架
«结论先行：MySQL 默认 REPEATABLE READ（RR）不是"更安全的隔离级别"，而是"更贵的隔离级别"。gap lock、next-key lock 在 RR 下是常态，在 READ COMMITTED（RC）下则大幅收缩。我
question
5 亿行非分区大表在线转按月分区：唯一键冲突与切换期数据同步怎么解
【背景】 MySQL 8.0.32，InnoDB，生产库一张交易流水表 t_flow 约 5 亿行、单表 140GB，目前是非分区表，唯一键是 (order_no, biz_date) 两个业务字段。业务侧 90% 查询都带 3 个月内的
discussion
冗余字段到底该不该进主表？反范式化的边界，DBA 和开发到底怎么吵
背景 做了 3 年 DBA，被开发问得最"理直气壮"的一类需求是："这个字段就为读方便一点，冗余到主表里吧，省得 JOIN。" 典型场景：订单主表 "t_order" 上挂着 "merchant_name"（商家名）、"status_tex
«结论先行：对同一行的 "UPDATE t SET cnt = cnt + 1 WHERE id = 1"，并发度上去之后慢的不是 SQL、不是索引、不是 buffer pool，而是 InnoDB 行锁的「FIFO 排队 + 50 秒 l
背景：MySQL 8.0.32，InnoDB，单表 order 约 3800 万行（约 95GB），1 主 2 从半同步（rpl_semi_sync_master_wait_for_slave_count=1），白天高峰 QPS 约 800
«结论先行：从库延迟不是"网络慢"，而是主库一条 2,348,000 行的大事务被从库单线程 SQL 线程串行回放。修它有三条路——拆事务（治本）、开 MTS 并行回放（缓解）、分库（重锤），三者各有代价，不能只挑一个。» 一、现象：凌晨对
已经到底了
article
标题
摘要