深入淺出空間索引為什麼需要空間索引

一、問題

先思考個常見的問題：如何根據自己所在位置查詢來查詢附近50公尺的poi（point of interest，比如商家、景點等）呢（圖1a）？

每個poi都有經緯度資訊，我用圖1b的sql語句在mysql中建立了poi_spatial的表，其中lat和lng兩個欄位來代表緯度和經度。為後續分析方便起見，我人造了40萬個poi資料。

二、傳統的解決思路

方法一：暴力方法

該方法的思路很直接：計算位置與所有poi的距離，並保留距離小於50公尺的poi。

插句題外話，計算經緯度之間的距離不能像求歐式距離那樣平方開根號，因為地球是個不規整的球體（圖2a），按最簡單的完美球體假設，兩點之間的距離函式應該如圖2b所示。

該方法的複雜度為：40萬*距離函式。我們將球體距離函式寫為mysql儲存過程distance，之後我們執行查詢操作（圖3），發現花費了4.66秒。

該方法耗時的原因顯而易見，執行了40萬次複雜的距離計算函式。

方法二：矩形過濾方法

該方法分為兩部：

a）先用矩形框過濾（圖4a），判斷乙個點在矩形框內很簡單，只要進行兩次判斷（ltmin

b）用球面距離公式計算位置與矩形框內n個poi的距離（圖4b），並保留距離小於50公尺的poi

矩形過濾方法的複雜度為：40萬*矩形過濾函式 + n*距離函式（n<<40萬）。

根據這個思路我們執行sql查詢（圖5）（注：

經度或緯度每隔0.001度，距離相差約100公尺，由此推算出矩形左下角和右上角座標

），發現過濾後正好剩下兩個poi。

此查詢花費了0.36秒，相比於方法一查詢時間大大降低，但是對於一次查詢來說還是很長。時間長的原因在於遍歷了40萬次。

方法三：b樹對經度或緯度建立索引

方法二耗時的原因在於執行了遍歷操作，為了不進行遍歷，我們自然想到了索引。我們對緯度進行了b樹索引。

此方法包括三個步驟：

a）通過b樹快速找到某緯度範圍的poi（圖6a），個數為m（m<40萬），複雜度為log(40萬)*過濾函式;

b）在步驟a過濾得到的m個poi中查詢某經度範圍的poi（圖6b），個數為n(n

c）用球面距離公式計算位置與步驟b得到的n個poi的距離（圖6c），並保留距離小於50公尺的poi

執行sql查詢（圖7），發現時間已經大大降低，從方法2的0.36秒下降到0.01秒。

三、b樹能索引空間資料嗎？

這時候有人會說了：「方法三效果如此好，能夠滿足我們附近poi查詢問題啊，看來b樹用來索引空間資料也是可以的嘛！」

那麼b樹真的能夠索引空間資料嗎？

1）只能對經度或緯度索引（一維索引），與期望的不符

我們期待的是快速找出落在某一空間範圍的poi（如矩形）（圖8a），而不是快速找出落在某緯度或經度範圍的poi（圖8b），想象一下，我要查詢北京某區的poi，但是b樹索引不僅給我找出了北京的，還有與北京同一維度的天津、大同、甚至國外城市的poi，當資料量很大時，效率很低。

2）當資料是多維，比如三維（x，y，z），b樹怎麼索引？

比如z可能是高程值，也可能是時間。有人會說b樹其實可以對多個字段進行索引，但這時需要指定優先順序，形成乙個組合字段，而空間資料在各個維度方向上不存在優先順序，我們不能說緯度比經度更重要，也不能說緯度比高程更重要。

3）當空間資料不是點，而是線（道路、地鐵、河流等），面（行政區邊界、建築物等），b樹怎麼索引？

對於面來說，它由一系列首尾相連的經緯度座標點組成，乙個面可能有成百上千個座標，這時資料庫怎麼儲存，b樹怎麼索引，這些都是問題。

既然傳統的索引不能很好的索引空間資料，我們自然需要一種方法能對空間資料進行索引，即空間索引。

下節將對空間索引分類體系、原理、優缺點及資料庫支援情況進行闡述（正在寫）。

深入淺出空間索引 為什麼需要空間索引