这个问题我之前做地理数据查询时也碰到过，处理跨国际日期变更线的经纬度范围查询确实容易踩坑，咱们一步步来拆解最合理的解决办法：

问题根源 #

首先得搞清楚为什么原来的语句失效：SQL里的BETWEEN是严格遵循左数值 ≤ 右数值的区间逻辑。当你要查询的经度范围是179.00到-179.00时，longitude BETWEEN 179.00 AND -179.00相当于找“大于等于179且小于等于-179”的数值，这显然不存在，所以返回空；反过来写BETWEEN -179.00 AND 179.00又会包含中间所有经度（从-179到179），完全不是你要的跨日界线的边界框。

最优解决方案：分场景判断 #

核心思路是先判断经度范围是否跨越日界线（即最小经度 > 最大经度），然后分两种情况构造查询条件：

场景1：边界框不跨日界线（最小经度 ≤ 最大经度） #

用你原来的正常语句即可，逻辑完全成立：

SELECT * FROM locations 
WHERE latitude BETWEEN ? AND ? 
  AND longitude BETWEEN ? AND ?;

参数顺序：最小纬度、最大纬度、最小经度、最大经度。

场景2：边界框跨日界线（最小经度 > 最大经度） #

这时候要把经度条件拆成**“大于等于最小经度” 或者 “小于等于最大经度”**，因为跨日界线的范围其实是包含了[179, 180]和[-180, -179]两个区间：

SELECT * FROM locations 
WHERE latitude BETWEEN ? AND ? 
  AND (longitude >= ? OR longitude <= ?);

参数顺序：最小纬度、最大纬度、最小经度（比如179.00）、最大经度（比如-179.00）。

通用SQL语句（自动适配两种场景） #

如果不想在应用层提前判断，也可以写一个兼容两种场景的SQL，用条件逻辑把两种情况合并：

-- 以MySQL为例，用用户变量简化参数重复问题
SET @min_lat = ?, @max_lat = ?, @min_lon = ?, @max_lon = ?;
SELECT * FROM locations 
WHERE latitude BETWEEN @min_lat AND @max_lat
  AND (
    -- 不跨日界线的情况
    (@min_lon <= @max_lon AND longitude BETWEEN @min_lon AND @max_lon)
    OR
    -- 跨日界线的情况
    (@min_lon > @max_lon AND (longitude >= @min_lon OR longitude <= @max_lon))
  );

应用层推导SQL的伪代码 #

如果是在应用代码里动态生成SQL，伪代码逻辑大概是这样：

# 伪代码示例（Python风格）
def fetch_locations_in_bbox(min_lat, max_lat, min_lon, max_lon):
    base_sql = "SELECT * FROM locations WHERE latitude BETWEEN ? AND ?"
    params = [min_lat, max_lat]
    
    if min_lon <= max_lon:
        # 不跨日界线，追加正常经度条件
        base_sql += " AND longitude BETWEEN ? AND ?"
        params.extend([min_lon, max_lon])
    else:
        # 跨日界线，追加拆分后的经度条件
        base_sql += " AND (longitude >= ? OR longitude <= ?)"
        params.extend([min_lon, max_lon])
    
    # 执行SQL并返回结果
    return execute_query(base_sql, params)

内容的提问来源于stack exchange，提问作者Dwight