地理位置處理—Redis的GeoHash和MySQL的geography類型（之後有空再詳細介紹）
最近比較忙，本來很早就想寫對比文章了，這裏先大致寫寫，等之後有空再詳細介紹吧。這個文章我本地MD筆記也有，以後再上傳到github。
1. MySQL的geography
- 適合查找某個指定範圍內的物體（比如一個多邊形內的）
- 適合需較高精確位置關係的場景。比如傳來一個用戶座標，如果需要較精確的定位，來確定用戶是否在A區域還是B區域，可以用這個。
- geography往往伴隨着函數計算傳入的點Point位置是否在某個區域Polygon內，這個據需要數據庫函數。因爲走函數等於每一行都需要計算，所以是不走索引的，需要全表查找，效率就很低。設置空間索引Spatial index，可以加速這一過程（具體原理沒細究，有興趣可以自己去查一查）。
前面提到函數操作，不走索引。可以瞭解下virtual column，虛擬列。
過去把函數操作的值另外存一列，比如插入時間，需要另外存個時間戳版本，可以數據庫寫個觸發器，插入時制動轉化然後存到新列裏面。但是這樣麻煩又低效。可以新建一列，設置爲虛擬列，其值是函數計算結果，這樣插入數據時虛擬列的值會自動計算，而且由於虛擬列直接存在數據字典而不是持久化到磁盤，效率很高（類似於函數索引了）。
2. Redis的GeoHash
- 適合只簡單獲取某二維點周圍範圍情況。比如當前位置周圍有多少用戶在線。
- 適合精度低的場景。這個和GeoHash的算法有關，其本身是把地圖二維化，把地圖一直切兩刀分成4塊。具體的塊狀大小，和傳入的經度、維度的有效位數有關。詳細算法那些這裏不講，有興趣可以到我github的DB筆記看看一些網絡文章的講解。
3. 兩者對比
下面對比，指的是實現的方式不復雜的情況。
-
位置關係精度：MySQL的geography > Redis的GeoHash
-
實現難易度： MySQL的geography > Redis的GeoHash
-
如果只是獲取某點周圍大致情況，效率：MySQL的geography < Redis的GeoHash
最好根據自己實際場景使用對應的技術，不是什麼難用什麼就對。