DBA

背景 做了 3 年大数据平台，最近半年在不同团队里反复撞同一个问题：业务方说「就一个 select count(*)，跑在主库上 200ms 就完了」，DBA 说「主库是交易的命脉，报表这种长 SQL 进来就是灾难」。争论到最后往往不是技术

背景： 带团队做表设计这 15 年，被业务方和开发问得最多、也最容易当场吵起来的一个问题，就是「这张表要不要加个 deleted 字段做软删除？」。我的体感是：几乎每个团队都有软删除，但很少有人能清楚说出「为什么加、加在哪些表、索引怎么配套

一、现象：一条 2ms 的权限校验，突然飙到 103ms 去年 Q4 给一套电商后台做慢查询巡检。核心链路是「登录用户 → 拉菜单列表」，SQL 长这样： SELECT m.menu_id, m.menu_name, m.parent_id

背景 我做了 8 年运维，其中 5 年在一家 200 人的互联网公司负责核心业务线的运维和 DBA 协作。数据订正（线上跑 UPDATE / DELETE）是我日常打交道最高频的"危险操作"之一。 热榜上大家在聊连接池、超时重试、mTLS

背景 做了 5 年 DBA，被问得最多的一句话是："这条 SQL 慢，你给加个索引不就完了？" 但换个场合，领导又会说："DBA 是要兜底整个库的性能的。" 这两句话同时成立，就变成 DBA 一个人既当裁判又当运动员：既要劝业务方改写法，又

一、现象：一条"看起来很简单"的查询，P99 卡在 1.8s 去年我们迁移订单中心到 MySQL 8.0.32，主表 "orders" 约 2.1 亿行，单表 190GB。客服后台有一个高频接口：查某用户最近的 20 条订单： SELECT

一、现象：主从延迟 47 秒，从库告警炸了 上个月给一套库存系统做巡检。核心表 "t_inventory_log"（42 亿行、单表 1.8TB、InnoDB、MySQL 8.0.32、binlog=row）。业务方一条批量回刷脚本： UP

背景 做了 3 年 DBA，治理慢查询时最常撞见的一类场景是：业务方拿着一张几千万甚至上亿行的流水表，让运营看板「实时」出聚合结果（今日 GMV、分渠道转化、库存周转），SQL 写得再漂亮，本质还是在扫大表。而社区里对「该不该预聚合」的立场

«结论先行：buffer pool 命中率不是越高越好，buffer pool 也不是越大越好。命中率 99.7% 时 P99 依然可以打到 800ms，因为「命中」不等于「无代价」——一次冷读抖动可以把 LRU young list 冲刷

背景： 做 DBA 这 8 年，我接手过的 MySQL 实例里，大约 60% 跑在默认的 REPEATABLE READ（RR），40% 被业务方或前任 DBA 调成了 READ COMMITTED（RC）。每次新团队来问我"隔离级别该用哪

一、现象：没人报警，但 INSERT 吞吐悄悄掉了 40% 背景：一套 MySQL 8.0.32 / InnoDB 的物流履约系统，核心表 "t_fulfillment_item"（履约明细），规模 4500 万行、单表数据 28.6GB、

一、现象：监控里那条「不致命」的曲线 先给背景。一套 MySQL 8.0.32 / InnoDB 的订单+账务系统，主库 "innodb_buffer_pool_size=32GB"、"innodb_purge_threads=4"、"in

背景：MySQL 8.0.36，单主 + 2 从（半同步 rpl_semi_sync_master_wait_for_slave=ON），主库 32C/128G/ESSD PL2，从库同规格但磁盘是 SSD。binlog 日均增长约 200

背景 做了 10 年 DBA，被业务方问得最多的一个问题就是："我们的表要爆了，下一步该怎么办？" 每次问这话的时候，团队里通常已经开始在四条路线之间摇摆： 1. 垂直扩容：升配，更大规格的实例（vCPU / 内存 / SSD 升级一档），

一、现象：一次机房断电，订单表少了 412 条 去年 11 月，一家电商客户机房突然断电（UPS 顶了 90 秒，但一台主机因内存吃紧提前 OOM 重启）。恢复后业务方发现：断电前 1 分钟内的下单里有 412 条「客户端收到 200、但订

背景 社区里已经有一篇《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》把「超时不是运维项」讲得很透了，我基本认同。但最近带团队治理一批慢查询时，我发现一个被绕过去的问题：应用侧的超时（HikariCP "connectionT

一、现象：一次「我刚下的单怎么不见了」的 P0 去年 12 月大促前压测，订单链路是 MySQL 8.0.36（主从架构，主 16C64G、从 16C64G，从库走只读流量），业务侧反馈：下单接口返回 200 后立刻调「我的订单」列表，每

背景：最近带团队做一张 2 亿行的订单流水表治理，业务方一上来就说"先分区吧，分区快"。我犹豫了很久——DBA 圈子里关于"分区表"的立场其实分裂得很厉害，今天想借这个帖把几种常见做法摊开聊聊。 常见分歧： 1) 分区党：RANGE 按 c

现象或背景 上个月给订单主表 "t_order"（2.4 亿行、单表 118GB，InnoDB，MySQL 8.0.32）补一个二级索引 "idx_status_create_time"，业务侧只给了一个 20 分钟的变更窗口，且要求全程不

背景：MySQL 8.0.36，InnoDB 单表（约 8000 万行），主键为自增 id。业务方反馈：连续 2 天内 id 出现约 3 万次的跳号，期间没有观察到批量插入，也没有触发器或 AFTER INSERT 钩子。 现象： 1) S