共 2 篇相关文章
这篇从同学的一个具体问题出发：MySQL里的`order by rand()`到底是怎么工作的。文章深入剖析了MySQL执行`ORDER BY`子句的底层机制。 作者详细拆解了两种核心实现路径：利用索引的“直接返回”与需要文件排序的“filesort”。关键在于，`order by rand()`由于其随机性，几乎总是无法利用索引，必须走filesort，甚至需要将全表数据读入临时表并计算随机值，这解释了它为何在数据量大时成为性能杀手。 文章的巧妙之处不止于点明问题，更提供了清晰的优化思路——摒弃`order by rand()`，转而采用`JOIN`子查询、`RAND() < limit`等替代方案来随机获取数据。这种从实现原理到实践优化的完整剖析，能帮助读者不仅知其然，更知其所以然，从而在实际开发中做出更优的技术选择。
这篇讲的是 MySQL 中 `rand()` 函数的工作原理。作者从实际查询中 `ORDER BY rand()` 的性能问题入手，带我们深入看了下它的底层实现。 核心思路是：MySQL 的 `rand()` 默认使用一种名为“线性同余”的算法来生成伪随机数。每次查询如果没有指定固定的随机种子（seed），MySQL 会基于当前时间等动态值生成一个种子，之后的一系列“随机数”都是由这个种子通过公式计算出来的。这就解释了为什么在一次查询里，`rand()` 对每一行返回的值是“固定”的（因为种子固定了），但不同查询之间结果却不同。 文章还点出了一个常见的误解：`rand()` 生成的随机数序列并不均匀，且存在可预测性。对于需要强随机性或安全性的场景，它并不适用。作者通过分析源码级别的细节，让我们明白了这个看似简单的函数背后的确定性逻辑，也理解了它为什么在大数据量下会成为性能瓶颈。 对日常写 SQL 的人来说，这篇文章提供了一个从“会用”到了解“为何这样用”的视角，下次面对随机查询的优化时，思路会更清晰。
