經緯度加密存儲：如何兼容區域範圍查詢

核心矛盾

經緯度屬於連續數值型數據，業務常需「矩形/圓形範圍查詢」（如「查詢某半徑內的門店」）。加密後若失去順序性或空間關係，將無法直接用索引範圍掃描。

方案對比

推薦架構：Z-order 曲線 + 範圍查詢

1. 編碼邏輯

// 將 (lat, lon) 縮放為整數
long latInt = (long)((lat + 90) * 1e6);
long lonInt = (long)((lon + 180) * 1e6);
// 交織位元生成 Z-order 值
long morton = interleaveBits(latInt, lonInt);
// 加密存儲 morton（可選 AES）
String encrypted = AES_encrypt(String.valueOf(morton));

2. 範圍查詢轉換

查詢矩形 [latMin, latMax] × [lonMin, lonMax] → 計算覆蓋的 Z-order 區間集合（通常分解為 1~N 個連續區間） → SQL WHERE morton BETWEEN ? AND ? → 應用層二次精確過濾。

3. 索引優化

• 對 morton 列建立 B+ 樹索引。
• 輔助存儲原始經緯度密文（或明文若允許），用於二次過濾。

工程落地建議

1. 若業務僅需「附近 5km」查詢，採用 Geohash（Base32 編碼）+ 前綴匹配，更簡單。
2. 嚴格合規需加密：使用 順序保持加密 (OPE) 僅加密經度或緯度單列，另一列明文存儲，組合查詢時需應用層解密驗證。
3. 避免自行設計加密算法，優先使用成熟庫（如 Google CryptDB、Microsoft Always Encrypted）。