标签频道
覆盖索引
该标签下的文章、提问与讨论帖。
背景 一张 40 列的宽表，行宽约 1.5KB，单表约 42GB，现有 5 个二级索引。写入画像：INSERT ~600 QPS + 状态 UPDATE ~200 QPS。 现象 一条高频查询（对账明细列表，~300 QPS）： SELEC
背景 我负责一套商户结算系统（MySQL 8.0.32 / InnoDB，单主 16C64G，buffer_pool 32G）。核心表 "t_trade_detail" 约 2800 万行，40 列宽表（大量 VARCHAR(128) 的业
背景 8 年 DBA，慢查询治理日常。最近接手一套结算系统（MySQL 8.0.34 / InnoDB，单主 16C64G，buffer_pool 40G），核心表 "t_settle_detail" 约 5200 万行、单表 38GB，写
【背景】 15 年 DBA，最近在给一套结算系统（MySQL 8.0.32 / InnoDB，单主 16C64G，buffer_pool 40G）做索引治理。核心表 t_settle_bill 约 6500 万行、单表 41GB，写 QPS
【背景】 做了 5 年 DBA，日常被业务方问得最多的一句话是：「这条查询 P99 高，能不能加个索引把它打下来？」我的默认反应是先看 EXPLAIN 和写入路径，再决定动不动索引。但最近半年复盘慢查询工单时我发现，团队里两种做法各占一半，
«结论先行：同一条 SQL 在 1.8 亿行表上，「二级索引过滤 + 回表」P99 = 38ms，改成「覆盖索引 + 松散索引扫描（loose index scan）」P99 = 2.1ms——18 倍差距，SQL 一个字没改，只改了索引定
«结论先行：覆盖索引不是免费的午餐。当 WHERE 条件选择性极低（命中行 / 扫描行 < 0.01%）时，「覆盖索引 + 逐行回表过滤」的随机 I/O 成本会显著高于「一次顺序全表扫描 + 内存过滤」——此时正确的动作是删索引，而不是加索
«结论先行：覆盖索引不是免费的午餐，它的收益是「省回表」，账单是「索引膨胀 + 写放大 + buffer pool 装得下更少的行」三笔。这三笔账里前两笔你在建索引时看得见，第三笔（缓存效率下降）往往要过两周、被别的查询拖慢后才暴露。我 1
«结论先行：「加了索引」≠「走了快路径」。慢查询里相当一部分不是没索引，而是索引选择性差、没做成覆盖索引、或者优化器在回表成本和全表扫描之间选错了。我 3 年里被「明明有索引却慢」坑过不止一次，这次把三件事拆开量化讲清楚。» 一、现象与背景
一、现象：一条"看起来很简单"的查询，P99 卡在 1.8s 去年我们迁移订单中心到 MySQL 8.0.32，主表 "orders" 约 2.1 亿行，单表 190GB。客服后台有一个高频接口：查某用户最近的 20 条订单： SELECT
«结论先行：软删除（"deleted_at" 列 + "WHERE deleted_at IS NULL"）用得越久，二级索引里「同一个 customer_id 下挂着一串已删除行」的簇就越大，优化器从「覆盖索引直接出结果」退化成「索引扫描
文
标题
摘要