本文主要是介绍基于PostGIS的慢查询引起的空间索引提升实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
前言
一、问题定位
1、前端接口定位
2、后台应用定位
3、找到问题所在
二、空间索引优化
1、数据库查询
2、创建空间索引
3、geography索引
4、再看前端响应
总结
前言
这是一个真实的案例，也是一个新入门的工程师很容易忽略的点。往往在设计数据库的时候忘了进行索引的构建，进而由此导致了查询的性能很拉胯。下面来简单还原一下事件的经过。在之前的博客中，原文博客地址如下：基于SpringBoot和PostGIS的震中影响范围可视化实践、解决Thymeleaf的地震震中距离展示[[]]双引号报错的问题，这两篇博客中都详细介绍了如何进行空间查询的实战。
在这些应用的建设过程当中，在进行震中范围定位时，我们发现了一个问题，就是页面请求后端的时间比较长，界面要等很久才能获取结果。 下面是我们进行网络跟踪的结果。
通过观察network网络请求可以很直观的看到，有一个接口的请求时间很慢，就是获取震中位置的接口最慢的接近4秒才返回数据。 到底是什么原因导致了请求这么慢呢？
本文将详细分析在PostGIS中，怎么排查数据查询慢接口，如何进行空间索引的构建，以及使用空间索引的正确姿势，通过空间索引的构建提升空间查询的效率。对致力于空间查询优化的小伙伴们有一定的参考价值。闲言少叙，下面正式进入正题。
一、问题定位
对于一个工程师而言，遇到问题是家常便饭。比如上面这个慢查询的问题，首先这个问题很容易重现，只要点击一个地震信息点，就会请求后台。我们通过去后台调试查看具体的问题。从前端作为入口，到后台方法的定义。我们来谈谈如何进行接口调试，以至于定位查询慢的问题。
1、前端接口定位
在浏览器中打开调试窗口，在刚刚打开的调试窗口中，可以看到网络请求一栏。在这一栏中，我们可以看到访问比较慢的接口地址。
这里可以看到很详细的请求地址，下面将参数列出来：
| 序号 | 参数名 | 值 |
| 1 | request url | http://192.168.31.64:8080/earthqadmin/eq/mapview/villageinfo |
| 2 | request method | post |
| 3 | payload | lng 117.03 lat 34.32 |
通过这里的请求url，我们可以找到后台对应的接口。由于这里没有采用网关模式部署，因此直接对接的是系统后台。
2、后台应用定位
在后台代码当中，我们找到对应的controller类，并找到了对应的方法定义，接口代码如下：
/**
* 震中位置5公里分析
* @param lng 经度
* @param lat 纬度
* @return
*/
@PostMapping("/villageinfo")
@ResponseBody
public AjaxResult earthinfo(String lng,String lat){List<EarthquakeVillageVo> list = earthquakeInfoService.findListByLngLat(lng, lat);AjaxResult ar = AjaxResult.success();ar.put("data", list);return ar;
}代码比较简单，直接接收参数，并将参数传递到service层（这里并不会消耗时间），我们来看看Service的定义。
@Override
public List<EarthquakeVillageVo> findListByLngLat(String lng, String lat) {return villageMapper.findListByLngLat(" 'point(" +lng+" "+lat+")' ");
}通过代码发现，这里也没有进行复杂计算，继续来看Mapper的处理逻辑：
static final String FIND_LIST_BY_LNG_LAT = "<script>"+ "with bp as ( select st_geomfromtext(${pointinfo},4326) :: geography tp ) "+ "select st_distance(t.geom :: geography, bp.tp) dist,t.address,t.village_name,t.lng,t.lat from biz_village t, "+ " bp where st_dwithin(t.geom :: geography, bp.tp, 5000 ) order by dist "+ "</script>";
@Select(FIND_LIST_BY_LNG_LAT)
List<EarthquakeVillageVo> findListByLngLat(@Param("pointinfo")String pointinfo);3、找到问题所在
通过接口的代码分析，我们发现其逻辑非常简单，最终只是去数据库进行空间查询。那由此我们可以将问题排查的方向从应用代码转移到数据库中。应该是数据库的查询性能导致了查询性能的下降。顺着这种思路，我们来进行数据库调优，尝试优化查询性能。
二、空间索引优化
为了验证我们的猜想，也同时为了让系统性能有一个提升，我们将执行的sql语句复制到navicate中进行性能验证。sql语句如下：
with bp as
(select st_geomfromtext('point(111.99 40.34)',4326) :: geography tp
)
select st_distance(t.geom :: geography, bp.tp),t.* from biz_village t,bp where st_dwithin(t.geom :: geography, bp.tp, 5000);1、数据库查询
数据库的表biz_village表的数据量在65W左右，这个量其实不算大。毕竟空间数据，上千万条数据都是有可能的。
首先我们在客户端工具navicate中执行上述语句，看一下实际的查询性能怎么样？来看一下实际的运行结果。执行时间1.79秒，确实有点慢。
上述语句在数据库中执行，确实比较慢，一共耗时1.8秒，导致后台接口的性能很差。由此证明我们的优化方向是正确的，的确是数据查询性能低导致访问慢。因此问题的关键就变成了查询优化。通常在数据库中的优化步骤是什么呢？优化成本最低的是索引。我们来看一下实际语句，这里用到一个空间函数st_dwithin()。
with bp as
(select st_geomfromtext('point(111.99 40.34)',4326) :: geography tp
)
select st_distance(t.geom :: geography, bp.tp),t.* from biz_village t,bp where st_dwithin(t.geom :: geography, bp.tp, 5000);首先我们来看一下数据库表索引，
惊讶的发现，表里面没有设计空间索引，因此来看一下执行执行计划：
很明显，这里面没有任何的索引生效，似乎查询慢也是意料之中。既然怀疑是索引问题，那么我们来创建数据库索引。
2、创建空间索引
这里使用以下语句进行空间所用的创建，创建索引耗时将近10秒。这也是为什么索引要提前创建，不然这些索引创建的时间成本也是挺高的，随着数据量的增大是个很恐怖的数字。
create index idx_biz_village_geom on biz_village using gist(geom)
> OK
> 时间: 9.447s在创建了空间索引后，来看一下查询性能是否提升。
然而并没有什么提升，难道是索引无效吗？继续打开执行计划看一下。发现其依然没有走索引。是不是很奇怪。
肯定有细心的朋友发现了问题，我们仔细来看一下where条件。
where st_dwithin(t.geom :: geography, bp.tp, 5000);在st_dwithin函数中，我们把原本的geometry类型转换为了geography，之所以转换是因为我们想精确计算范围，比如5公里。众所周知，在4326坐标系下，如果使用geomerty的距离计算单位是度，而不是我们熟悉的米。我们先将转换去掉，先来验证索引是否有效。
仔细对比一下之前的查询计划，发现这里用到了索引查询，0.1表示0.1度，并不是0.1米。请各位朋友注意。 再来执行以下sql语句，是不是很惊喜，查询时间只需要0.006秒。这说明空间索引的构建对于提升空间查询速度帮助很大。
3、geography索引
这里需要思考一个问题，我们给geometry设计了索引，那geography为什么没有用呢？这也好理解，这两个其实都是空间数据库中空间数据的两种表达。使用geography主要为了精确的计算距离，而使用度来转换的话，不同坐标系下会有一定的误差。但是怎么进行geography的数据索引构建呢？可以使用下面语句来进行。
create index idx_biz_village_geom_gp on biz_village using gist((geom::geography))
> OK
> 时间: 10.513s
空间索引创建完毕后，再来看执行计划：
再次执行空间查询，效果依然很明显。优化后执行时间耗时0.009秒。
从1.8秒到0.009秒，速度提升了 200倍。
4、再看前端响应
经过上述的空间索引优化后，我们来看一下界面的展示情况。经过数据库优化，界面访问速度大幅提升，可以实现毫秒级响应。用户体验进一步的提升。
总结
在应用程序的开发过程中，一定要重视索引的使用和创建，好的索引应用能提升应用的查询性能。不好的索引设计，将会使用户体验大大降低。最后提一点最佳实践建议，针对于空间索引，一定要提前建立，因为空间索引的创建耗时太长。在上述的空间索引中，既有geometry的空间索引，又有geography的索引，个人建议，如果不是为了精确计算米级查询，只需要创建geometry索引即可。这样也减少空间索引的创建成本。
以上就是本文的主要内容，本文将详细分析在PostGIS中，怎么排查数据查询慢接口，如何进行空间索引的构建，以及使用空间索引的正确姿势，通过空间索引的构建提升空间查询的效率。对致力于空间查询优化的小伙伴们有一定的参考价值。行文仓促，定有不当之处，如有不当之处，欢迎各位专家和朋友批评指正，十分感谢。在空间索引优化过程中参考了以下博客资料，站在巨人的肩膀上，才能看得更高更远。
参考资料地址：
1、postgis性能优化实战之-周边搜索查询
这篇关于基于PostGIS的慢查询引起的空间索引提升实践的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
