共 2 篇相关文章
这篇讲的是 MySQL 中 `GROUP BY` 到底是如何实现的。作者从一个常见的误解出发——很多人根据执行计划中的 `Using filesort` 认为，`GROUP BY` 是“先排序，后分组”。但真的是这样吗？ 作者通过一个对比实验来验证：在查询中显式添加 `ORDER BY NULL` 后，`filesort` 消失了，结果行的出现顺序也发生了改变。这说明排序并非分组的必要步骤，而是后续的一个可选操作。 文章深入到了算法层面。MySQL 实际采用的是一种更高效的哈希分组算法：它会创建一个临时表，遍历原表数据时，根据分组键（key）进行哈希查找。若 key 存在则更新计数，不存在则插入新行。整个过程无需预先排序，时间复杂度是 O(n)。 最后，文章解释了默认情况下我们看到的结果是“有序”的，那仅仅是因为 MySQL 默认在分组后追加了一次排序操作。这与“先排序后分组”的直觉正好相反。
这篇讲的是在处理数据库查询时，一个看似简单却很实际的需求：如何过滤仅部分字段重复的记录。很多开发者习惯性地使用 `SELECT DISTINCT`，但它判断的是整行数据的唯一性。文章正是从这个常见的认知起点出发，点明了当业务要求基于特定字段（如姓名、电话）来去重，而允许其他字段（如ID、创建时间）不同时，`DISTINCT` 就无能为力了。 作者接着对比了两种关键的解决方案。一种是传统的 `GROUP BY` 结合聚合函数（如 `MAX`、`MIN`）来选取每组中的特定记录，这适用于明确需要保留哪条数据的场景。另一种是更现代的窗口函数方法（如 `ROW_NUMBER()`），它能为每组重复数据按规则排序并打上编号，再筛选编号为1的记录，这种方式在逻辑上更灵活，尤其适合复杂排序或需要保留“最新”、“第一条”等场景。 文章没有停留在语法层面，而是强调了选择哪种方案背后的思考：你需要明确“去重”的业务标准究竟是什么，以及对性能和结果完整性的要求。对于想要精准控制去重逻辑的开发者来说，理清 `DISTINCT`、`GROUP BY` 和窗口函数之间的差异与适用边界，是写出高效且正确查询的关键一步。
