标签频道
DBA
该标签下的文章、提问与讨论帖。
现象与背景：一次慢查询治理的实战 在我们团队接手的某日志审计系统中，核心表 "t_audit_log" 规模达到了 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业
现象或背景 我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建了索引本身成了事故」的场景。 先给一个具体的数：我们库
现象与背景：一次慢查询治理的实战 在我们团队接手的某日志审计系统中，核心表 "t_audit_log" 规模达到了 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业
背景：我们正在管理一个 MySQL 8.0 多租户库，核心表约 2.8 亿行，单主 32C128G，头部租户占 41%。日常运行中，我们发现部分 SQL 的执行计划在不同租户参数下不一致，出现计划漂移（plan drift）现象。这导致部分
背景 一张 40 列的宽表，行宽约 1.5KB，单表约 42GB，现有 5 个二级索引。写入画像：INSERT ~600 QPS + 状态 UPDATE ~200 QPS。 现象 一条高频查询（对账明细列表，~300 QPS）： SELEC
背景 做了 5 年 DBA，日常治理慢查询时我习惯用 "max_execution_time"（MySQL 8.0.22+，单位 ms）做"安全阀"：给一条已知可能跑飞的批量 UPDATE 设 2s 上限，超时直接 KILL，避免一条慢 S
结论先行 **MySQL 8.0.13+ 的表达式索引（Functional Index）让 "WHERE UPPER(email) = ?"、"WHERE JSON_EXTRACT(payload, '$.status') = ?"、"W
背景 我负责一套商户结算系统（MySQL 8.0.32 / InnoDB，单主 16C64G，buffer_pool 32G）。核心表 "t_trade_detail" 约 2800 万行，40 列宽表（大量 VARCHAR(128) 的业
«结论先行：慢日志（slow_log）/ performance_schema 里的 "query_time" 是「从收到语句到返回结果」的墙钟时间，它把等锁的挂起时间原封不动算进去了。你按 query_time 排 Top N 去优化，很
背景 8 年 DBA，慢查询治理日常。最近接手一套结算系统（MySQL 8.0.34 / InnoDB，单主 16C64G，buffer_pool 40G），核心表 "t_settle_detail" 约 5200 万行、单表 38GB，写
«结论先行：MySQL 返回的 "1213 (ER_LOCK_DEADLOCK)" 和 "1205 (ER_LOCK_WAIT_TIMEOUT)" 在 InnoDB 里是两个完全不同的失败路径——前者是「检测器选中了你、立即回滚、锁当场释放
背景 MySQL 8.0.32 / InnoDB，单主 32C128G（NVMe），"innodb_buffer_pool_size=48G"，"innodb_purge_threads=4"，"innodb_log_file_size=4
«结论先行：InnoDB 二级索引的"膨胀"（叶子页数远超理论值）是长期运行最容易被漏诊的隐性成本——它不产生慢日志、不触发任何告警，但会让随机写页分裂从 0.3% 涨到 11%，UPDATE 改索引列时 P99 从 4.2ms 爬到 31
背景：MySQL 8.0.36，InnoDB，16C64G 单机，innodb_buffer_pool_size=48G，innodb_change_buffering=all（默认）。核心表 t_order 约 4500 万行、含 8 个
结论先行 「先修哪条」不该拍脑袋，应该算出来。 我在 4000 万行的 "t_trade_order" 上治 23 条慢 SQL、人手只够修 3 条的场景里，把优先级拆成了一个三因子公式： "Score = 影响分(链路 × 缓存兜底 ×
背景 3 年运维，负责一套 MySQL 8.0.36 订单库（主 16C64G + 2 台从，binlog=row，已开 LOGICAL_CLOCK 并行复制 worker=8，GTID 全开）。最近在给故障切换（MHA 自托管脚本）写「该
结论先行 InnoDB 里 "DELETE" 是「标记删除 + 空间回收进 free list」，不是「物理抹掉文件里的字节」。删掉 1.7 亿行后 ".ibd" 文件大小几乎不变，这不是 bug、不是磁盘没刷、更不是数据没删掉——被删行占
【背景】 做了 8 年 DBA，最常被开发同学拿来"拍板"的一句话是："这个 SQL 慢，你加个索引不就完事了？" 我见过太多这样的链路： - 一个订单列表接口，一次请求拆成 12 条子查询（N+1 的变体），单条 P50 只有 3ms，但
背景 MySQL 8.0.36（InnoDB，16C64G，buffer_pool 48G），核心表 "t_order" 约 2 亿行，主键 "id"（bigint 自增）。业务是高频点查 + 点更新（按 PK），QPS 约 8k，隔离级别
背景 我负责一套 SaaS 多租户计费系统，主库 MySQL 8.0.36（云 RDS，16C64G，"innodb_buffer_pool_size=48G"）。核心表 "t_invoice_item" 约 2.3 亿行，有一条按 "te
已经到底了
文
标题
摘要