WordPress与phpMyAdmin执行相同距离计算SQL为何排序结果不一致
核心本质：非确定性排序
当前SQL仅将计算得到的distance作为ORDER BY的唯一排序键，这是同距离条目顺序不一致的直接原因。
SQL标准未对排序键值完全相等时的行返回顺序做强制约定，MySQL也严格遵循该设计逻辑：只要排序键值存在重复，数据库对这些行的返回顺序就是无约定、非确定的，可能随以下因素动态变化：
- 查询执行的扫描路径：如果查询命中不同索引（如主键聚集索引、二级索引），读取行的初始顺序就会存在差异
- 排序实现方式：小结果集的内存排序、大结果集的磁盘文件排序，在处理等值排序键时的行排列逻辑无统一规则
- 表数据物理状态变化：如碎片整理、统计信息更新、新数据写入导致的物理存储顺序调整，都会影响等值行的返回结果
wpdb和phpMyAdmin两个场景下出现顺序差异，本质是两个数据库连接执行查询时触发了不同的执行逻辑，最终导致等值行的排列没有保持一致。哪怕不更换执行环境，仅在同一个wpdb脚本中连续执行两次相同查询，同距离条目的顺序也有可能出现变化。
距离值完全相等的原因
使用Haversine公式计算地理距离时，受浮点数计算精度限制，多个实际距离极近的位置，计算后输出的浮点值会出现完全相等的情况，这属于正常的计算表现，不是代码逻辑bug。
只需在ORDER BY子句中增加次级排序规则，给所有等值的distance行提供固定排序键，就能彻底消除顺序不一致的问题。
例如按post_id固定同距离条目的顺序，修改后的排序部分为：ORDER BY distance ASC, l.post_id ASC
如果需要同距离按post_id倒序排列，只需将最后一个排序键改为DESC即可。修改后无论数据库采用何种执行计划，同距离条目的顺序都会完全固定，在任何场景下执行的结果都会保持一致。
额外优化提示：当前使用
HAVING distance < 50做距离过滤的效率偏低，因为HAVING是在全量结果集计算完成后才执行过滤，无法利用索引提前缩减数据范围。如果后续需要优化查询性能，可以考虑在数据写入时预计算并存储经纬度相关索引，在数据量较小时继续使用当前的Haversine实时计算逻辑即可。
内容的提问来源于stack exchange，提问作者user15335432
