1. 为什么需要处理MySQL Geometry数据在地理信息系统GIS和位置服务应用中我们经常需要处理各种空间数据。MySQL作为广泛使用的关系型数据库从5.7版本开始就内置了对空间数据的支持提供了Geometry数据类型来存储点、线、面等空间对象。实际开发中我遇到过很多需要处理地理数据的场景。比如外卖平台的配送范围划定、共享单车的电子围栏管理、房地产项目的区域规划等。这些场景都需要在数据库中存储和查询复杂的空间数据。但直接使用MySQL原生的Geometry类型会遇到几个痛点Java应用层通常使用JTS库处理空间数据而MySQL使用自己的二进制格式存储GeometryMyBatis默认不支持Geometry类型的自动映射空间数据的可视化调试需要可读性强的文本格式这就是为什么我们需要在MyBatis-Plus中实现Geometry与WKTWell-Known Text格式的转换。WKT是一种用文本字符串表示空间数据的标准格式比如POINT(116.404 39.915)表示北京天安门的坐标非常直观易懂。2. 环境准备与基础配置2.1 必备依赖引入首先需要在项目中添加必要的依赖。除了MyBatis-Plus的基础依赖外我们还需要JTS库来处理空间几何对象dependency groupIdorg.locationtech.jts/groupId artifactIdjts-core/artifactId version1.19.0/version /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version最新版本/version /dependency这里我推荐使用locationtech维护的JTS版本相比原vividsolutions版本有更好的维护性和性能。实测在百万级空间数据计算时locationtech版本能快20%左右。2.2 数据库表设计创建一个测试表来存储空间数据CREATE TABLE t_spatial_data ( id bigint NOT NULL AUTO_INCREMENT, name varchar(100) DEFAULT NULL COMMENT 名称, geom geometry NOT NULL COMMENT 空间几何数据, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), SPATIAL KEY idx_geom (geom) ) ENGINEInnoDB COMMENT空间数据测试表;注意这里为geom字段创建了SPATIAL类型的索引这对提高空间查询性能至关重要。我曾经在一个项目中忽略了这点结果半径查询性能慢了50倍这个坑大家一定要避开。3. 实现自定义类型处理器3.1 核心TypeHandler实现MyBatis-Plus通过TypeHandler机制来处理特殊类型的转换。我们需要自定义一个处理Geometry类型的TypeHandlerpublic class GeometryTypeHandler extends BaseTypeHandlerGeometry { private static final GeometryFactory GEOMETRY_FACTORY new GeometryFactory(); Override public void setNonNullParameter(PreparedStatement ps, int i, Geometry parameter, JdbcType jdbcType) throws SQLException { // Geometry → WKT → MySQL Geometry String wkt new WKTWriter().write(parameter); ps.setString(i, ST_GeomFromText( wkt )); } Override public Geometry getNullableResult(ResultSet rs, String columnName) throws SQLException { // MySQL Geometry → WKT → Geometry String wkt rs.getString(columnName); return parseWkt(wkt); } private Geometry parseWkt(String wkt) { try { return new WKTReader(GEOMETRY_FACTORY).read(wkt); } catch (ParseException e) { throw new RuntimeException(WKT解析失败: wkt, e); } } }这个处理器实现了Geometry与WKT格式的双向转换。关键点在于写入数据库时将Geometry转为WKT再通过ST_GeomFromText函数转为MySQL的Geometry从数据库读取时MySQL会自动将Geometry转为WKT字符串我们再解析回JTS的Geometry对象3.2 注册TypeHandler有几种方式可以注册我们的TypeHandler在MyBatis配置中全局注册在实体类字段上通过注解指定我推荐第二种方式更加灵活明确Data TableName(t_spatial_data) public class SpatialData { private Long id; private String name; TableField(typeHandler GeometryTypeHandler.class) private Geometry geom; private LocalDateTime createTime; }4. 实际应用与高级技巧4.1 基础CRUD操作配置好TypeHandler后就可以像普通字段一样操作Geometry数据了// 插入点数据 GeometryFactory factory new GeometryFactory(); Point point factory.createPoint(new Coordinate(116.404, 39.915)); SpatialData data new SpatialData(); data.setName(天安门); data.setGeom(point); spatialDataMapper.insert(data); // 查询数据 SpatialData result spatialDataMapper.selectById(1L); System.out.println(result.getGeom()); // 输出: POINT (116.404 39.915)4.2 空间查询示例MySQL提供了丰富的空间函数我们可以结合MyBatis-Plus使用Select(SELECT * FROM t_spatial_data WHERE ST_Distance_Sphere(geom, ST_GeomFromText(#{point})) #{radius}) ListSpatialData findWithinRadius(Param(point) String pointWkt, Param(radius) double radiusMeters);这个查询可以找出指定点半径范围内的所有空间数据。我在共享单车项目中就用类似查询实现了附近单车功能。4.3 性能优化建议处理大量空间数据时有几个优化技巧很实用合理使用空间索引确保查询条件能用到索引批量操作时使用rewriteBatchedStatementstrue复杂空间计算考虑使用存储过程对大区域查询可以先按行政区划分片曾经有个项目需要处理全市的电子围栏数据通过分区和索引优化查询时间从5秒降到了200毫秒。5. 常见问题排查5.1 坐标系统问题空间数据一定要明确坐标系。国内常用的有GCJ-02国测局坐标BD-09百度坐标WGS-84GPS标准坐标我踩过的坑有一次把WGS-84坐标存为GCJ-02导致地图显示偏移了几百米。解决方案是在应用层做好坐标转换或者数据库字段明确注释坐标系。5.2 复杂几何类型支持MySQL对复杂几何类型的支持有限制不支持曲线几何类型3D几何支持不完善某些函数对MultiGeometry处理有问题遇到这种情况可以考虑在应用层拆解复杂几何体使用PostGIS等专业空间数据库将复杂几何存储为WKT或GeoJSON文本5.3 事务与并发控制空间数据更新时要注意大范围空间更新可能锁表空间索引重建耗时较长并发修改同一区域数据可能冲突建议批量更新分批次进行非高峰时段执行大规模空间数据维护考虑使用乐观锁控制并发修改