一、問題

　　先思考個常見的問題：如何根據自己所在位置查詢來查詢附近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<lat<LtMax; LnMin<lng<LnMax），落在矩形框內的POI個數為n（n<<40萬）；

　　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<m)，複雜度為m*過濾函式；

　　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樹怎麼索引，這些都是問題。

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

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