分类频道
数据库
该分类下的文章、提问与讨论帖。
【背景】MySQL 8.0.32 / InnoDB，单库 32C/128G，innodb_buffer_pool_size=64G。日志明细表 log_event 约 3 亿行，PK=id（自增），索引 idx_ct (create_tim
discussion
大表 DDL 在线变更：双写对账 vs 锁表停机，你们团队到底怎么选？
【背景】 社区里连接池、超时重试、异步化都聊得挺透了，但有一个更「硬」的问题我很少看到被正面讨论：一张千万级甚至亿级行的大表，要加列、改索引、改类型，你的团队到底怎么落地？ 我自己踩过的场景：一张 8000 万行的订单流水表，业务要求「加一
一、现象：一条"看起来很简单"的查询，P99 卡在 1.8s 去年我们迁移订单中心到 MySQL 8.0.32，主表 "orders" 约 2.1 亿行，单表 190GB。客服后台有一个高频接口：查某用户最近的 20 条订单： SELECT
discussion
慢查询日志到底是「治理入口」还是「噪音源」？聊聊你的取舍
背景 社区里关于「慢查询该加索引还是改写 SQL」的讨论已经很多了（id=49 的讨论帖、id=19 的三件套文章我都认真看过，方向基本认同）。但我想把问题再往前挪一步：在「定位」这一环，大家到底把慢查询日志（slow_query_log）
背景：MySQL 8.0.32 / InnoDB，单主单从，主库承载支付清结算，核心表 t_settle_record 约 2.8 亿行，innodb_purge_threads=4，隔离级别 REPEATABLE READ。业务方有一个凌
«结论先行："INSERT ... ON DUPLICATE KEY UPDATE"（下称 ODKU）是"写法上最方便"的幂等手段，但它把"唯一索引冲突检查"和"UPDATE"塞进同一个事务、同一把行锁里完成，在高 QPS + 高重复率场景
discussion
软删除、硬删除、还是归档？大表数据生命周期管理，你们团队到底怎么选
背景 做了 10 年 DBA，被业务方问得最多的第二个问题（第一个是"表要爆了怎么办"）就是："这条数据能不能删？" 每次回答"能删"，对方都要追问一句："那万一以后要查呢？"——于是 "is_deleted" 字段就这么诞生了。然后三年后
«结论先行：RocksDB 的写毛刺，90% 不是「写慢」，而是「写被自己人卡住了」——前台写路径本身（memtable 追加 + WAL 落盘）在 NVMe 上稳定 1~3ms，真正让 P99 飙到 200ms 的，是后台 compact
背景： 我负责一套订单系统，核心表 t_order 约 4200 万行、单表含所有二级索引约 18GB，InnoDB，MySQL 8.0.32，单主单从。业务写入 QPS 日常 800~1200（以 INSERT 为主，少量 UPDATE
一、现象：主从延迟 47 秒，从库告警炸了 上个月给一套库存系统做巡检。核心表 "t_inventory_log"（42 亿行、单表 1.8TB、InnoDB、MySQL 8.0.32、binlog=row）。业务方一条批量回刷脚本： UP
背景 做了 5 年大数据平台，我在不同团队见过同一个问题被讨论至少五次：一张订单表，到底是把商品名、商家名、收货人、支付渠道全冗余进去（宽表），还是只存外键、查询时 JOIN 四张表（窄表）？ 两种做法我都深度参与过。宽表那张 1.2 亿行
«结论先行：InnoDB 的主键是聚簇索引的物理顺序，主键的随机性直接决定写入是顺序 IO 还是随机 IO。把 UUID v4 换成雪花 ID，同样的批量写入 P99 从 1.8s 降到 52ms，收益 35 倍——这不是"ID 格式"问题
背景：MySQL 8.0.36 / InnoDB，隔离级别 REPEATABLE READ。用户地址表 user_address，PK=id (bigint auto)，二级索引 idx_user (user_id bigint, addr
«结论先行：软删除（"deleted_at" 列 + "WHERE deleted_at IS NULL"）用得越久，二级索引里「同一个 customer_id 下挂着一串已删除行」的簇就越大，优化器从「覆盖索引直接出结果」退化成「索引扫描
discussion
运营看板的大表聚合查询：现算 vs 预聚合，到底在什么阈值下该切换？
背景 做了 3 年 DBA，治理慢查询时最常撞见的一类场景是：业务方拿着一张几千万甚至上亿行的流水表，让运营看板「实时」出聚合结果（今日 GMV、分渠道转化、库存周转），SQL 写得再漂亮，本质还是在扫大表。而社区里对「该不该预聚合」的立场
一、现象：一条"写入"接口，把磁盘 IO 打到 92% 先说结论：这次写入慢，不是慢 SQL、不是连接池、也不是网络，而是"主键用 UUID 导致 InnoDB 随机写 + 页分裂"。把主键换回自增后，同一台机器、同一份流量，写入 P99
【背景】 MySQL 8.0.32 / InnoDB，单库承载订单查询与归档。核心表 t_order 约 8000 万行、数据文件 15.2GB（含二级索引约 22GB），innodb_buffer_pool_size=16GB（机器 64
结论先行 批量插入慢，十有八九不是 SQL 写得差，而是「一次只提交一条」+「驱动没把 batch 拼成 multi-row INSERT」+「每条都强制刷盘」三件事叠在一起。我们一个埋点落库服务，单机写入吞吐从 1200 行/s 提到 9
«结论先行：buffer pool 命中率不是越高越好，buffer pool 也不是越大越好。命中率 99.7% 时 P99 依然可以打到 800ms，因为「命中」不等于「无代价」——一次冷读抖动可以把 LRU young list 冲刷
discussion
分库分表之后，跨片 JOIN 和聚合查询到底该谁来扛？
背景 做了 10 年大数据平台，最近半年在两个团队里反复撞到一个"分完之后才暴露"的坑：分库分表把单表 80GB 拆到了 16 个分片，单片查询 P99 从 120ms 降到 8ms，看起来很完美；结果第二天报表团队来找——"用户维度的 G