地理位置处理—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
最好根据自己实际场景使用对应的技术，不是什么难用什么就对。