用左前缀分组索引配合 MIN 直接取得每组最小值

MySQL 单表查询每组最小值时，可以让 GROUP BY 的列构成有序联合索引的最左前缀，再把 MIN 的目标列紧接在分组列之后。例如按仓库、物料分组取最低成本，索引可写成 (warehouse_id, material_id, unit_cost)。这种形状具备 Loose Index Scan 的基本条件，但最终是否采用，仍由优化器选定的计划说明。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/group-by-optimization.html

先限定改造范围：只返回每组最小值

假设一张库存成本明细表，同一个仓库与物料有多条记录，报表只要最低成本。我会先把返回值限定为“仓库、物料、最低成本”这三个字段，再考虑索引。这样查询需求和索引条件容易对应，也不会无意中把“最低成本”扩展成“最低成本所在的整行”。这里是设计取舍说明，不是线上改造实录。

本文按 MySQL 8.4 手册讨论已有优化机制，所谓迁移，是把原查询和索引调整为匹配当前需求的形式，不涉及某次升级新增能力。真正的改动范围是索引列顺序、查询投影和聚合表达式。没有实测数据时，不应把这种结构描述为固定倍数的加速。

如果业务需要那条明细的 id 或其他附属信息，仅靠 MIN(unit_cost) 不会自动返回与最小值对应的一整行；并列最小值如何处理也需要额外定义。不要在分组结果中随意加一个非分组的明细 id，期待数据库替你选择正确记录。本文始终保持单表分组聚合的范围。

让索引前缀与聚合列连续排列

示例中，仓库列与物料列形成完整分组前缀，成本列紧随其后，MIN 只作用于成本列。使用整列索引，避免字符串前缀索引等额外条件。表结构还把成本设为 NOT NULL，使演示中的业务语义保持简单。

-- 独立演示表：分组列在前，取最小值的成本列紧随其后。
CREATE TABLE stock_cost_sample (
    id BIGINT NOT NULL PRIMARY KEY,
    warehouse_id INT NOT NULL,
    material_id INT NOT NULL,
    unit_cost DECIMAL(12,2) NOT NULL,
    KEY idx_group_min (warehouse_id, material_id, unit_cost)
) ENGINE=InnoDB;

-- 同一物料在同一仓库可有多笔成本记录。
INSERT INTO stock_cost_sample
    (id, warehouse_id, material_id, unit_cost)
VALUES
    (1, 10, 501, 8.40),
    (2, 10, 501, 7.90),
    (3, 10, 502, 5.20),
    (4, 20, 501, 9.10),
    (5, 20, 501, 8.70);

-- 仅返回分组键和最小成本，不要求携带原始记录的其他字段。
SELECT warehouse_id, material_id, MIN(unit_cost) AS min_cost
FROM stock_cost_sample
GROUP BY warehouse_id, material_id;

按样例数据推导，仓库 10 的物料 501 最小成本为 7.90，物料 502 为 5.20，仓库 20 的物料 501 为 8.70。这些是根据 INSERT 数值推导的结果，本文未运行数据库，也不提供虚构的 EXPLAIN 输出。五条样例只用于理解语义，不能代表生产成本分布。

从键排列看，同一分组的成本值在有序索引中具有相邻关系。Loose Index Scan 利用这样的键组织减少对组内所有键的逐个读取；它是访问方式，不是换一种 SQL 聚合含义。具体读取量和收益依赖实际数据，不应把“每组一行结果”直接等同于任何场景都只发生固定次数的物理 I/O。

旧查询中哪些变化会破坏适用条件

-- 按物料分组不构成此索引的左前缀，不能沿用原条件判断。
SELECT material_id, MIN(unit_cost) AS min_cost
FROM stock_cost_sample
GROUP BY material_id;

-- SUM 改变了聚合任务，不能套用本文的 GROUP BY + MIN 条件。
SELECT warehouse_id, material_id, SUM(unit_cost) AS total_cost
FROM stock_cost_sample
GROUP BY warehouse_id, material_id;

上面两条查询用来说明为什么不能原样套用本例条件，并不是说它们一定全表扫描或不能使用任何索引。特别是 Loose Index Scan 不适用时，MySQL 仍可能选择其他索引访问方式。判断应针对具体 SQL 和具体计划，不要把优化名称当成所有分组查询都必须达到的目标。

额外 WHERE 条件也必须放回完整索引结构里分析。尤其对查询引用的其他索引部分，官方条件涉及常量等值约束；不能看见一个等号，就认为它可以随意填平分组前缀或 MIN 列之间的间隙。本例有意不加额外过滤，先把最简单、最容易解释的布局建立清楚。

用 EXPLAIN 阅读计划，不把覆盖索引当作证明

-- 只展示计划阅读方法；本文未连接数据库或执行此语句。
EXPLAIN
SELECT warehouse_id, material_id, MIN(unit_cost) AS min_cost
FROM stock_cost_sample
GROUP BY warehouse_id, material_id;

阅读传统 EXPLAIN 时，留意 key 和 Extra 字段。官方将 Using index for group-by 列为 Loose Index Scan 的计划说明标记。单独看到 Using index，不能当作相同证明：覆盖索引能从索引提供所需数据，与按组跳过大量键，是两个不同问题。

我更倾向于把“语义正确”“结构具备条件”“计划实际选择”分别记录。第一项由业务需要决定，第二项由 SQL 与索引布局决定，第三项在目标数据库环境中观察。这样即使小样例没有出现期望标记，也不会为了追一个计划词而改掉报表含义。

实际部署前，使用有代表性的数据分布看计划与资源消耗，尤其关注每组记录数量和分组数量的比例。本文仅提供读者可用的计划阅读语句，不在自动写作过程中执行 SQL、启动服务或收集性能指标。不能由示例 DDL 推导出生产环境必然采用某一个计划。

迁移清单与常见问题

迁移时先固定分组口径和最小值字段，再确认现有索引是否已经覆盖同一排列，避免重复添加近似索引。随后比较查询结果，并检查生产写入负担与索引空间。在大表上实施 DDL，应结合现有变更流程安排，不能把演示建表语句直接当成对已有表的上线指令。

MIN 与 MAX 可以同时使用吗？本文讨论的条件允许这两类聚合，但它们应引用同一列，并满足该列紧随分组列的要求。不要将 MIN(cost) 与 MAX(other_column) 直接视为本例的等价扩展。

有索引就一定减少到每组一次读取吗？不能这样承诺。索引结构只是适用条件的一部分，实际计划、过滤和存储访问都需要结合目标环境理解。

GROUP BY 会保证结果按仓库排序吗？业务需要显示顺序时，应显式写 ORDER BY，并针对完整查询重新看计划，不把当前观察到的结果排列当作接口保证。

对只需要分组键和最小值的报表，这种连续索引布局值得优先评估；需要附带明细整行、复杂过滤或其他聚合时，应先重新描述任务，保留查询语义，再决定适合的索引访问方式。

参考：MySQL 8.4 GROUP BY Optimization。