SQL(MySQL,PostgreSQL,SQL Server)的快速最近位置查找器[关闭]
Posted
技术标签:
【中文标题】SQL(MySQL,PostgreSQL,SQL Server)的快速最近位置查找器[关闭]【英文标题】:Fast nearest-location finder for SQL (MySQL, PostgreSQL, SQL Server) [closed] 【发布时间】:2016-01-20 19:17:25 【问题描述】:有人可以帮助进行以下查询连接而不是子选择吗?它来自本教程:http://www.plumislandmedia.net/mysql/haversine-mysql-nearest-loc/。
结果证明,在有大量行(400 万行)的情况下实现这一点非常慢。我认为子选择是根本原因,但我不知道如何将其变成连接。
SELECT
zip,
primary_city,
latitude,
longitude,
distance
FROM
(
SELECT
z.zip,
z.primary_city,
z.latitude,
z.longitude,
p.radius,
p.distance_unit * DEGREES(ACOS(COS(RADIANS(p.latpoint)) * COS(RADIANS(z.latitude)) * COS(RADIANS(p.longpoint - z.longitude)) + SIN(RADIANS(p.latpoint)) * SIN(RADIANS(z.latitude)))) AS distance
FROM zip AS z
JOIN
(
/* these are the query parameters */
SELECT
42.81 AS latpoint,
-70.81 AS longpoint,
50.0 AS radius,
111.045 AS distance_unit
) AS p ON 1 = 1
WHERE
z.latitude BETWEEN p.latpoint - (p.radius / p.distance_unit)
AND p.latpoint + (p.radius / p.distance_unit)
AND z.longitude BETWEEN p.longpoint - (p.radius / (p.distance_unit * COS(RADIANS(p.latpoint))))
AND p.longpoint + (p.radius / (p.distance_unit * COS(RADIANS(p.latpoint))))
) AS d
WHERE distance <= radius
ORDER BY distance
LIMIT 15
【问题讨论】:
【参考方案1】:我不相信你可以在这里做任何事情。我想您的长时间运行时间来自于通过所有这些计算处理 400 万条记录所需的大量 CPU。
您最里面的子查询只有 4 个常量,它们与您的主子查询交叉连接,因此您无法在此处执行任何操作来帮助加快速度。这将是一个洗涤。
你的主子查询(大的 SELECT 语句)在这里完成所有工作,并被包裹在主查询中以节省处理,因为距离需要计算 3 次,除非 mysql 的优化器执行了某种奇迹并认识到该计算被使用了三遍。
无论如何,这可能是一个性能更差的版本,它删除了最外层的查询:
SELECT
z.zip,
z.primary_city,
z.latitude,
z.longitude,
p.distance_unit * DEGREES(ACOS(COS(RADIANS(p.latpoint)) * COS(RADIANS(z.latitude)) * COS(RADIANS(p.longpoint - z.longitude)) + SIN(RADIANS(p.latpoint)) * SIN(RADIANS(z.latitude)))) AS distance
FROM zip AS z
JOIN
(
/* these are the query parameters */
SELECT
42.81 AS latpoint,
-70.81 AS longpoint,
50.0 AS radius,
111.045 AS distance_unit
) AS p ON 1 = 1
WHERE
z.latitude BETWEEN p.latpoint - (p.radius / p.distance_unit)
AND p.latpoint + (p.radius / p.distance_unit)
AND z.longitude BETWEEN p.longpoint - (p.radius / (p.distance_unit * COS(RADIANS(p.latpoint))))
AND p.longpoint + (p.radius / (p.distance_unit * COS(RADIANS(p.latpoint))))
WHERE p.distance_unit * DEGREES(ACOS(COS(RADIANS(p.latpoint)) * COS(RADIANS(z.latitude)) * COS(RADIANS(p.longpoint - z.longitude)) + SIN(RADIANS(p.latpoint)) * SIN(RADIANS(z.latitude)))) <= p.radius
ORDER BY p.distance_unit * DEGREES(ACOS(COS(RADIANS(p.latpoint)) * COS(RADIANS(z.latitude)) * COS(RADIANS(p.longpoint - z.longitude)) + SIN(RADIANS(p.latpoint)) * SIN(RADIANS(z.latitude)))) LIMIT 15
您可以看到z.distance
的所有实例都被替换为用于计算查询的WHERE
和ORDER BY
部分中的距离的公式。
如果您想取消保存常量的交叉连接子查询......您也可以这样做,但现在您会因最后一次更改而失去性能,并且因失去交叉连接而失去可读性:
SELECT
z.zip,
z.primary_city,
z.latitude,
z.longitude,
111.045 * DEGREES(ACOS(COS(RADIANS(42.81)) * COS(RADIANS(z.latitude)) * COS(RADIANS(-70.81 - z.longitude)) + SIN(RADIANS(42.81)) * SIN(RADIANS(z.latitude)))) AS distance
FROM zip AS z
WHERE
z.latitude BETWEEN 42.81 - (50.0 / 111.045)
AND 42.81 + (50.0 / 111.045)
AND z.longitude BETWEEN -70.81 - (50.0 / (111.045 * COS(RADIANS(42.81))))
AND -70.81 + (50.0 / (111.045 * COS(RADIANS(42.81))))
WHERE 111.045 * DEGREES(ACOS(COS(RADIANS(42.81)) * COS(RADIANS(z.latitude)) * COS(RADIANS(-70.81 - z.longitude)) + SIN(RADIANS(42.81)) * SIN(RADIANS(z.latitude)))) <= 50.0
ORDER BY 111.045 * DEGREES(ACOS(COS(RADIANS(42.81)) * COS(RADIANS(z.latitude)) * COS(RADIANS(-70.81 - z.longitude)) + SIN(RADIANS(42.81)) * SIN(RADIANS(z.latitude)))) LIMIT 15
所以......最后,这是一个有趣的练习,但我认为没有任何优点,这些变化肯定有一些缺点。
【讨论】:
它实际上并没有进行全面扫描。经纬度/经度被编入索引并完成 50 公里约束。然后根据 50 公里半径内的点计算半正弦公式。 是的,但它仍然需要将:111.045 * DEGREES(ACOS(COS(RADIANS(42.81)) * COS(RADIANS(z.latitude)) * COS(RADIANS(-70.81 - z.longitude)) + SIN(RADIANS(42.81)) * SIN(RADIANS(z.latitude))))
应用于每条记录才能做出决定,因为距离基于子查询中的参数,我认为这是非常密集的, CPU 方面。以上是关于SQL(MySQL,PostgreSQL,SQL Server)的快速最近位置查找器[关闭]的主要内容,如果未能解决你的问题,请参考以下文章
sql MySQL“World”数据库的PostgreSQL端口。
无法从 Data Fusion 连接 Cloud SQL mySql / postgreSQL 实例
将数据从 SQL Server/PostgreSQL 移动到 MySQL