标签频道
EXPLAIN
该标签下的文章、提问与讨论帖。
现象与背景：一次慢查询治理的实战 在我们团队接手的某日志审计系统中，核心表 "t_audit_log" 规模达到了 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业
现象与背景：一次慢查询治理的实战 在我们团队接手的某日志审计系统中，核心表 "t_audit_log" 规模达到了 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业
背景 MySQL 8.0.32 / InnoDB，单主 32C/128G，"innodb_buffer_pool_size=64G"。核心表 "t_msg_log" 约 1.2 亿行，PK=id，二级索引 "idx_user_ts (use
【背景】 做了 15 年 DBA，联合索引的列序设计几乎天天碰。社区里"加索引 vs 改 SQL"的取舍（id=1581 的讨论、id=19 的三件套文章）我已经看过了，方向没有分歧。但我想把问题再聚焦一层：不是"加不加"，而是"列怎么排"
«结论先行：EXPLAIN 的 "rows" 列不是「这条 SQL 要扫多少行」，而是 InnoDB 用「采样页估算的基数」除以「等值条件值个数」算出来的一个期望值。当数据分布严重倾斜、且你那个「头部值」恰好落在没被采样的页里时，"rows
背景 MySQL 8.0.32 / InnoDB，一张 900 万行的工单表 "t_ticket"，有两个单列索引： - "idx_priority"（INT，分布极不均匀：P1 占 1.2%、P2 占 8%、P3 占 90.8%） - "
背景 MySQL 8.0.32，InnoDB，订单流水表 "t_order_flow" 约 2.4 亿行，按 "created_at" 做 RANGE 月分区（约 30 个分区），二级索引 "idx_merchant_time (merch
背景：MySQL 8.0.34，InnoDB，业务库有一张订单流水表 t_order_flow（约 1.2 亿行，PK=id，二级索引 idx_merchant_time (merchant_id, created_at)、idx_stat
背景：订单表 t_order 约 4200 万行，InnoDB，MySQL 8.0.32，已建联合索引 idx_ab (a, b)，其中 a 是商户ID（高基数，单值查询命中 200~3000 行不等），b 是创建时间（datetime）。
一、现象与背景：加了索引，P99 反而涨了 30% 上个月给一套订单系统做慢查询治理。核心表 "t_order" 规模：1200 万行、单表 3.1GB、InnoDB、MySQL 8.0.32。业务方甩来一条高频查询： SELECT id,
结论先行 慢查询治理不是「加索引」三个字能糊弄的，正确顺序是：先定位（EXPLAIN + 慢日志）→ 再判断（是索引问题还是写法问题）→ 最后才是加索引或改写 SQL。我 3 年在 DBA 岗位上踩过的坑，绝大多数都败在「上来就加索引」这一
文
标题
摘要