MySQL报错4105，ER_SRS_INVALID_LATITUDE_OF_ORIGIN导致定位失败，远程帮忙修复中

开始）

用户那边突然说系统报错了,地图相关的功能全都用不了，页面上显示定位失败，赶紧登录服务器去看日志，发现MySQL抛出了一个之前没怎么见过的错误，错误代码是4105，完整的错误信息是“ER_SRS_INVALID_LATITUDE_OF_ORIGIN”，这个错误直接导致了一个存储过程执行失败，而这个存储过程正是用来处理地理位置计算的核心逻辑。

一开始有点懵,因为最近也没有动过数据库的结构，特别是空间数据相关的部分，先尝试重启了MySQL服务，想着是不是服务临时抽风，但重启之后问题依旧，说明不是临时状态的问题，然后检查了那个出问题的存储过程，代码看起来也没什么改动，逻辑是正常的，这就奇怪了，代码没动，服务没动，怎么突然就不行了呢？

静下心来仔细看这个错误信息。“ER_SRS_INVALID_LATITUDE_OF_ORIGIN”，把它拆开看。“SRS”应该是Spatial Reference System的缩写，也就是空间参考系统，这跟地图坐标有关。“INVALID_LATITUDE_OF_ORIGIN”直接翻译是“无效的原始纬度”，合起来大概意思是，MySQL在使用某个空间参考系统时，发现里面定义的“原始纬度”这个参数是无效的。

问题可能出在数据库里某个空间参考系统的定义上,根据MySQL的官方文档说明，SRS定义了一系列参数，用来描述如何将球面的经纬度坐标映射到平面的地图坐标上，这个“原始纬度”是其中一个关键参数，如果这个参数的值超出了合理的范围（对于某些投影方式，原点纬度应该在正负90度之间），MySQL在进行空间计算时就会抛出这个4105错误。

是哪个SRS定义出了问题呢？通过查询信息，发现错误很可能与一个名为“EPSG:3857”的空间参考系统有关，这个系统非常常用，就是网络地图（比如Google地图、OpenStreetMap）普遍使用的Web墨卡托投影，它的SRID（空间参考系统ID）通常是3857。

根据MySQL官方文档和社区的一些故障报告,在MySQL某些版本（特别是8.0.x早期的一些版本）中，内置的EPSG:3857定义可能存在一个瑕疵，其“latitude_of_origin”参数被设置成了一个无效的值，在正常情况下，Web墨卡托投影的原点纬度应该是0度（赤道），但有问题的定义里可能被错误地设置成了其他值，比如90度或者一个非数值，平时可能没用到这个特定参数相安无事，但一旦执行某些特定的空间函数或计算，触发了对这个无效参数的校验，错误就暴露出来了。

原因找到了,是MySQL自带的一个系统级SRS定义有bug，那怎么修复呢？不能直接去修改MySQL内置的系统表，那样不安全且可能被后续升级覆盖，正确的方法是使用MySQL提供的管理函数，手动删除有问题的SRS定义，然后重新添加一个正确的。

具体的操作步骤,根据资料显示，大概是这样子的：需要以具有足够权限（如root）的用户登录MySQL数据库，执行一个删除语句，将SRID为3857的SRS定义从系统的information_schema的ST_SPATIAL_REFERENCE_SYSTEMS表中移除，命令类似于 DELETE FROM information_schema.ST_SPATIAL_REFERENCE_SYSTEMS WHERE srid = 3857; 但实际操作中，可能需要使用 DROP SPATIAL REFERENCE SYSTEM 3857; 这样的SQL语句，具体语法需要查证当前MySQL版本的文档。

删除之后,需要重新添加一个正确的EPSG:3857定义，这需要使用 CREATE SPATIAL REFERENCE SYSTEM 语句，并完整地、准确地填写所有必要的参数，包括名称、定义机构、坐标系统类型、投影方法，以及关键的参数如“latitude_of_origin”（必须设置为0.0）、“central_meridian”（中央经度，通常为0.0）、“false_easting”（东移假定值）、“false_northing”（北移假定值）等，这些参数的正确值可以从权威的地理空间网站（如epsg.io）查询获得。

在实际远程操作的时候,每一步都要非常小心，先在一个测试环境上验证这个修复方案是否有效，确认无误后再在生产环境操作，操作前务必对数据库进行完整的备份，防止操作失误导致更严重的问题，执行删除和重建SRS的语句后，需要重新启动MySQL服务，或者尝试使用 FLUSH PRIVILEGES; 之类的命令（虽然主要针对权限，但有时能帮助刷新系统缓存），确保新的SRS定义被正确加载，立刻再次运行之前报错的SQL语句或触发那个出问题的功能，检查4105错误是否消失，地理位置计算是否恢复正常。

整个处理过程就是这样,核心就是定位到有问题的系统级SRS定义，然后用正确的定义替换它，这个问题也提醒我们，即使在看似稳定的数据库系统软件中，也可能存在一些隐藏的bug，在特定条件下会被触发，保持MySQL版本更新到较新的稳定版，有时也能避免这类问题。 结束）