当前位置：首页 > 问答 > 正文

MySQL报错3565，ER_WARN_SRS_NOT_FOUND_AXIS_ORDER问题分析和远程快速修复方法分享

邝冷亦
问答
2026-01-03 16:37:35
3

这个错误通常在你使用MySQL 8.0及以上版本，并且处理地理空间数据（比如地图坐标）时遇到，它是一个“警告”而非“错误”，但如果不处理，可能会导致你的地理空间查询结果不准确，甚至程序功能失常。

问题根源分析

要理解这个警告,首先得知道一个叫“空间参考系统”（SRS）的东西，你可以把SRS想象成一张地图的“规则说明书”，地球是圆的，但地图是平的，要把球面展平，就需要一套数学规则，SRS就定义了这套规则，包括使用的坐标系、单位（米还是度）、以及最重要的——轴顺序。

轴顺序指的是：当我们表示一个点（比如北京的经纬度）时，是先写经度还是先写纬度？是 (经度, 纬度) 还是 (纬度, 经度)？这听起来像个细节，但搞错了就会差之千里，传统上，不同组织和标准有不同的习惯：

EPSG:4326：这是一个极其常用的SRS，它使用WGS 84坐标系（也就是GPS使用的坐标系），在很长一段时间里，许多软件（包括旧版MySQL）默认按照 纬度-经度 (Latitude-Longitude) 的顺序来处理这个坐标系的数据。
GIS行业标准：但根据GIS领域的现代标准（如ISO 19111），EPSG:4326的正确轴顺序应该是 经度-纬度 (Longitude-Latitude)。

MySQL在8.0版本后加强了对地理空间数据的标准兼容性，它内置了一个SRS字典，里面记录了每个SRS的正确信息，包括轴顺序，当你使用一个SRS（比如EPSG:4326）时，MySQL会去字典里查它的定义。

错误3565 “ER_WARN_SRS_NOT_FOUND_AXIS_ORDER” 就在这个环节出现了，它意味着：

你正在使用的SRS（大概率是EPSG:4326）在MySQL的SRS字典中没有被明确定义轴顺序。
MySQL无法确定应该用哪种顺序（经度-纬度还是纬度-经度）来解析或计算你提供的数据。
为了避免给出完全错误的结果,MySQL不会中断你的操作，而是抛出这个警告，并回退到旧的、可能不标准的默认行为（通常是纬度-经度）。

触发场景举例

你可能会在以下操作中遇到这个警告：

创建包含地理空间数据类型（如GEOMETRY, POINT, POLYGON）的表。
使用ST_GeomFromText('POINT(116.4 39.9)')这样的函数将文本转换为空间对象。
执行空间计算,如计算两个点之间的距离（ST_Distance）。
导入一个包含空间数据的SQL文件。

远程快速修复方法

这里的“远程”通常指你通过命令行或图形化工具连接数据库服务器进行操作，修复的核心思路是：为MySQL的SRS字典补上缺失的轴顺序定义。

以下是几种直接且快速的方法,推荐按顺序尝试：

更新SRS定义（最推荐、最根本的解决方法）

MySQL报错3565，ER_WARN_SRS_NOT_FOUND_AXIS_ORDER问题分析和远程快速修复方法分享

这是MySQL官方推荐的方法,你需要有足够的权限（通常是SYSTEM_VARIABLES_ADMIN权限）来修改SRS系统表。

连接数据库：使用你的客户端（如MySQL Shell、Navicat、命令行mysql）连接到出问题的MySQL服务器。

执行以下SQL语句,这会从官方资源更新EPSG:4326的定义，其中包括正确的轴顺序：

UPDATE mysql.st_spatial_reference_systems
SET definition = 'GEOGCS["WGS 84", DATUM["World Geodetic System 1984", SPHEROID["WGS 84", 6378137, 298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich", 0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943278, AUTHORITY["EPSG","9122"]], AXIS["Lat", NORTH], AXIS["Lon", EAST], AUTHORITY["EPSG","4326"]]'
WHERE srs_id = 4326;

关键部分在于 AXIS["Lat", NORTH], AXIS["Lon", EAST]，它明确定义了轴顺序。

执行后,必须重启MySQL服务，才能使新的SRS定义生效，重启服务后，警告应该就会消失。

在SQL语句中显式指定轴顺序（临时或代码级解决方案）

如果你没有权限修改服务器级的SRS字典,或者想在不重启服务的情况下快速让某个特定查询正常工作，可以使用这个办法。

MySQL报错3565，ER_WARN_SRS_NOT_FOUND_AXIS_ORDER问题分析和远程快速修复方法分享

MySQL提供了一些特定函数来覆盖默认的轴顺序：

ST_SRID(geom, 4326, ‘axis-order=long-lat’)
在创建几何对象时,使用ST_GeomFromText(‘POINT(116.4 39.9)’, 4326, ‘axis-order=long-lat’)

原本会报警告的查询：

SELECT ST_Distance(ST_GeomFromText(‘POINT(116.4 39.9)’, 4326), ST_GeomFromText(‘POINT(121.5 31.2)’, 4326));

可以修改为：

SELECT ST_Distance(
    ST_GeomFromText(‘POINT(116.4 39.9)’, 4326, ‘axis-order=long-lat’),
    ST_GeomFromText(‘POINT(121.5 31.2)’, 4326, ‘axis-order=long-lat’)
);

这个方法的好处是无需修改服务器配置,但需要在所有涉及该SRS的SQL语句中都加上这个选项，比较繁琐。

升级MySQL版本（长远之计）

如果你使用的MySQL 8.0是一个较早的版本（比如8.0.1x），这个问题可能在更新的版本（如8.0.30以后）中已经被修复，SRS字典的定义更加完善，考虑将MySQL升级到一个较新的稳定版，也是一个一劳永逸的办法。

MySQL报错3565是一个关于空间坐标轴顺序不明确的警告,虽然不致命，但会影响计算准确性，最彻底的解决方法是通过SQL更新mysql.st_spatial_reference_systems表来修正SRS定义并重启服务，如果权限不足，则可以在SQL函数中显式添加axis-order=long-lat选项作为临时方案，在处理任何地理空间数据时，明确轴顺序都是一个非常重要的良好实践。

（注：以上分析和解决方法参考了MySQL官方文档中关于空间参考系统的章节以及社区中如Percona、Stack Overflow等技术站点的相关讨论。）