SQL（MySQL，PostgreSQL，SQL Server）的快速最近位置查找器[关闭]

Question

有人可以帮助进行以下查询连接而不是子选择吗？它来自本教程：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

Answer 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

所以......最后，这是一个有趣的练习，但我认为没有任何优点，这些变化肯定有一些缺点。