如何清除 MySQL 确定性函数结果缓存?

How to clear MySQL deterministic function result cache?

我有一个庞大的地理数据库,我经常需要将其与实时地理数据进行比较,以确定每个 Latitude:Longitude 最近的位置。位置 table 确实包含许多行,但很少添加新记录。根据数百万实时数据确定最近的位置,即使在实施了矩形距离比较算法(而不是通过 Haversine 进行实际比较)之后,查询速度也非常慢,这让我们痛苦地付出了代价。

我想将此比较转换为 DETERMINISTIC 函数,该函数应该真正带来静态结果的真正性能提升。

但是,我希望每周 MySQL 到 reset/rebuild 这个确定性结果缓存。就像,我希望 MySQL 到 return 我的 Latitude:Longitude 对与我的位置 table 比较得到相同的结果,但持续 7 天。 7 天后,我很有可能会向 table 添加新位置,我希望 MySQL 考虑到向 table 添加了新行,开始重建确定性函数结果缓存,最好不要重新启动 MySQL 服务器。

注意:符合 MariaDB 的解决方案是非常好的:)

更正:请原谅我在MySQL中使用那个词。到目前为止我能理解,对于所有输入都相同的确定性函数,结果不会改变,这让我觉得 MySQL 实际上并不倾向于执行或处理函数内部的指令,而是 returns 是同一组输入值的先前计算值,因此,它肯定会将这些值缓存在某处(我不知道在哪里),因此表现得就像只是通过列表查找或类似的东西。我想我在这里用 CACHE 重载了 OPTIMIZER :(

======== 编辑技术说明 ========

Table: data (around 4.5 Bl records)
ID BIGINT(20) PK AI
Terminal BIGINT(20) NOT NULL <= Foreign key
Latitude FLOAT (8, 5) NULL (indexed)
Longitude FLOAT (8, 5) NULL (indexed)
Location <= Foreign key

Table: location (around 10k records)
ID BIGINT(20) PK AI
Name VARCHAR(250) NOT NULL UNIQUE
Latitude FLOAT (8, 5) NOT NULL (indexed)
Longitude FLOAT (8, 5) NOT NULL (indexed)

'data'table 的传入数据是实时的,每秒大约 1500 个数据(我们有一个每秒无限迭代的过程)。大约 85% 的数据包含坐标,我们正试图在实时捕获流时实时确定最近的位置。

我认为您误解了 DETERMINISTIC 作为 CREATE FUNCTION 的选项的含义。

并不代表函数的结果是memoized。没有函数结果的缓存。没有刷新此缓存的命令,因为结果未保留。

DETERMINISTIC的含义主要影响二进制日志:

https://mariadb.com/kb/en/create-function/#not-deterministic

The [NOT] DETERMINISTIC clause also affects binary logging, because the STATEMENT format can not be used to store or replicate non-deterministic statements.

也就是说,non-deterministic 函数如果在副本上执行可能会 return 不同的结果,因此如果您在修改数据的 SQL 语句中使用该函数,则该事件的二进制日志格式必须是 ROW 以确保在副本上应用相同的更改。

还有一个模糊的参考:

The optimizer may choose a faster execution plan if it known that the function is deterministic.

但是没有给出这种情况的例子。这可能是罕见的,因为它会产生显着的性能差异。

我认为这不会对您的用例进行有效的性能优化。

Function 不是您可以获得性能的地方。 (比尔对此进行了讨论。)算法是您可以获得性能的地方。 (我将深入探讨。)

simple-minded 选择涉及检查每一百万行的距离。正如您所发现的,这是不可扩展的。

接下来是 INDEX(lat, lng), INDEX(lng, lat) 并使用边界框。这给出了一个数量级的加速。

类似的改进来自使用 SPATIAL 值和索引。

我在 Find Nearest 中详细介绍了这 3 种方法。 link 还提供了两种算法,它们的速度又快了一个数量级,但对于仅几百万行,您可能不需要那么大的改进(和复杂性)。