你好呀，我是歪歪。

先给大家推荐一个躺在我收藏夹里面好几年的一个好东西。

/monthly/

数据库内核月报，是阿里云的数据库内核团队从 2014 年开始维护的，内容主要是数据库内核和运维相关经验，这里的数据库不限于 MySQL，还有 PolarDB、PostgreSQL、MongoDB 等等。

链接点进去，你会发现页面非常简洁，标题只有年月，再点击进去，会有详细的文章链接。

比如这是最新一期，2024 年 11 月的月报内容：

月报具体的篇数不确定，有时候只有一篇，有时候又有好几篇。这是今年 9 月的月报内容：

由于这些文章都有阿里云数据库内核团队的背书，质量还是非常有保障的。

这个链接我忘记我收藏了多久了，但是至少也有四年左右的时间了。每隔一个月左右的时间，就点进这个链接里面看看最新的文章，已经养成了一个习惯了。

但是我也不会每篇都读，由于工作中使用的数据库就是 MySQL，所以我几乎只看 MySQL 相关的内容，其他的 DB 我感觉我是学不动了。

早期还会点开链接浏览一下大致内容，现在是看标题，只要不是 MySQL 相关的，都不会点进去看了。

这里面的文章大主题都是数据库相关的，但是又分为很多的分支，比如 BUG 分析、源码分析、特性介绍等等。

歪师傅去年写过这样一篇文章：《我试图扯掉 order by 的底裤。》

里面就是介绍了当 order by 遇到 limit 时可能会遇到的一个看起来像是 “BUG” 的现象。

当时查阅资料的时候，就找到了“数据库内核月报”的一篇文章：

/monthly/201…

是 2015 年的一篇文章，和我去年写的那篇文章，背景是一模一样的。

当时除了 MySQL 官方文档对于 Limit 关键字的解释外，这篇文章也给我指引了一定的方向。

而我当时来这里找到这篇文章，也纯属“有枣没枣打一杆子”再说，看看有没有相关文章描述过类似的问题，这个用“分页”关键词还真找到了。

此外，还用“Order By”关键词找到了这篇文章，也在我理解源码的时候给到了一定的帮助：

/monthly/202…

说真的，我遇到过很多 MySQL 数据库的问题，能在这里面找到的相关资料的不多，但是找一下这个动作，反正也不麻烦，总比你直接去网上大浪淘沙的找好多了。

但是当你真的自己尝试去搜索的时候，你会发现这个“月报”不支持搜索啊，每月的标题都是“数据库内核月报 － yyyy/MM”，搜不到里面的内容，怎么办？

你当然可以把每个月的链接里面对应的文章标题和链接自己搞一份出来，方便自己阅读。

但是你要相信，像这种高质量的宝藏网站，你的困难，就是大家的困难，所有肯定已经有“好事之人”帮你解决了困难。

这里提供两个歪师傅在用的。

第一个是这个项目：

/tangwz/db-m…

这里面按照类别对文章进行分类打标处理，有每篇文章的标题和具体链接，但是是人工维护，时效性上可能慢点。

好处是对于历史文章方便检索，在页面 Ctrl+F 直接搜就完事了。

第二个是这个项目：

/vimiix/ali-…

这个项目我是在第一个项目的 Issues 里面看到的，是一个“好事之人”今年才搞的。

提供了一个更加友好的页面，文章也是采用爬虫实现了“每天 0 点探测是否有新的文章，有的话增量更新”：

也是挺不错的，非常感谢这些“好事之人”的贡献。

说回标题

看到这里你可能发现了，这文不对题啊，怎么回事？

别急，这不就是来了嘛。

我为啥突然想给你分享这个“数据库内核月报”这个数据库相关的博客。

是因为前段时间的一个周末遇到一个读者问我关于 MySQL 的一个问题：

当时我看到这个问题的时候，刚刚在峡谷里面选完英雄，准备 carry 全场。

在游戏开始之前，刚好这个问题弹出来，然后我快速的提取了一下关键词：SQL、聚合函数、查询结果不确定...

我在脑海里面检索信息的时候，就像是有一个流程图，通过上面这几个关键词，在加上当时脑子处理信息的时候，还把 order by 和 group by 搞混了，我啪的一下，很快啊，就联想到了前面提到的，之前写过的那篇关于 order by 的文章。

SQL 都没仔细看，当时我就下结论了：这题我见过，和文件排序逻辑有关。

想着也是一个素材，于是就让读者帮忙提供了一下 SQL 文件，我收藏到了“素材库”的标签下：

我当时甚至还给他分享了我之前写的这篇文章：

然后我就去峡谷了。

昨天整理素材库的时候，我又看到了这个素材。

看到这个 SQL 的第一眼，我当时就觉得“不好，前面整错了”：

SELECT customer_id, min(order_date) order_date FROM delivery;

你仔细看看，这 SQL 是想干啥？

是要从 delivery 表中获取 order_date 类的最小值和最小值对应的 customer_id 吗？

这 SQL 不应该这样写啊？

写出来的这个 SQL 是没有任何意义的呀，

因为没有 group by 语句，这个 SQL 的查询结果是返回整个表中最小的 order_date 以及任意一个 customer_id，具体是哪个这个取决于数据库系统的实现，反正这个“任意一个”是没啥具体意义的。

这也就和读者提前提出的“查询的 customer_id 数据是不准确的”呼应上了。

具体是咋不准确的呢？

看一下这个 SQL 的执行结果：