Go使用pgx查询PostGIS报无效几何错误原因及查询效率疑问

第一版查询语句报错原因 #

第一版写法报错的根源是参数占位符被写在了单引号包裹的字符串内部，数据库不会替换字符串里的占位符。
你写的'SRID=4326;POINT($1 $2)'对PostgreSQL来说就是个普通字符串，里面的$1、$2不会被识别成需要绑定外部传入参数的位置标记，只会被当成字符串的一部分。PostGIS拿到这个字符串去解析几何的时候，发现坐标位置是$1、$2这种根本不是数字的内容，自然会抛出几何无效的解析错误。
你在pgAdmin里手动把$1、$2替换成实际数字之后，整个字符串就是合法的WKT几何格式，没有待替换的占位符，当然可以正常运行。
别尝试用字符串拼接的方式把坐标拼到WKT里传参，很容易引发SQL注入问题，你后面改用函数构造点的写法在安全性上是对的。

空间查询效率优化方案 #

你现在用ST_Distance算距离再判断是否小于1000米的写法，不是效率最高的实现。数据量上去之后会非常慢，因为ST_Distance会逐行计算两个点的精确距离，完全用不上空间索引，属于全表扫描逻辑。
要做到高效的邻近查询，只需要做两处调整：

• 给location字段建GIST空间索引，这是空间查询能走索引的前提，建索引语句如下：

CREATE INDEX idx_steps_location ON steps USING GIST (location);

• 查询的时候用ST_DWithin替换ST_Distance做距离过滤：ST_DWithin会优先走空间索引，快速把符合距离范围的候选记录筛出来，只需要对少量候选数据做精确距离校验，性能比全表算ST_Distance快好几个量级。改完的查询语句如下：

searchQuery = "SELECT DISTINCT(id) FROM steps WHERE ST_DWithin(ST_SetSRID(ST_MakePoint($1, $2), 4326)::geography, location, 1000)"

额外提一句：ST_MakePoint的参数顺序是经度在前、纬度在后，传参的时候别把lat和lng传反了，不然坐标位置会错。

内容的提问来源于stack exchange，提问作者Big_Boulard