网络安全最新基于PostGIS的慢查询引起的空间索引提升实践_st_dwithin查询慢，2024年最新王者笔记

如何自学黑客&网络安全

黑客零基础入门学习路线&规划

初级黑客
1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）

2、渗透测试基础（一周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础（一周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）

4、计算机网络基础（一周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）
恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；如果等保模块学的好，还可以从事等保工程师。薪资区间6k-15k

到此为止，大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗？

如果你想要入坑黑客&网络安全，笔者给大家准备了一份：282G全网最全的网络安全资料包评论区留言即可领取！

7、脚本编程（初级/中级/高级）
在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力.

如果你零基础入门，笔者建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习；搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP， IDE强烈推荐Sublime；·Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，不要看完；·用Python编写漏洞的exp,然后写一个简单的网络爬虫；·PHP基本语法学习并书写一个简单的博客系统；熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)；·了解Bootstrap的布局或者CSS。

8、超级黑客
这部分内容对零基础的同学来说还比较遥远，就不展开细说了，附上学习路线。

网络安全工程师企业级学习路线

如图片过大被平台压缩导致看不清的话，评论区点赞和评论区留言获取吧。我都会回复的

视频配套资料&国内外网安书籍、文档&工具

当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。

一些笔者自己买的、其他平台白嫖不到的视频教程。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

这是一个真实的案例，也是一个新入门的工程师很容易忽略的点。往往在设计数据库的时候忘了进行索引的构建，进而由此导致了查询的性能很拉胯。下面来简单还原一下事件的经过。在之前的博客中，原文博客地址如下：基于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条件。

学习路线：

这个方向初期比较容易入门一些，掌握一些基本技术，拿起各种现成的工具就可以开黑了。不过，要想从脚本小子变成黑客大神，这个方向越往后，需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！