应使用ST_GeomFromText('POINT(longitude latitude)', 4326)配合单事务批量插入，禁用POINT()拼字符串（无SRID致索引失效）、控制每批500–1000行防包截断、开启rewriteBatchedStatements=true、验证坐标顺序与SRID一致性。
直接用 ST_GeomFromText() 批量插入，配合显式 SRID 和单事务提交——这是唯一能兼顾正确性、性能和索引可用性的做法。
为什么不能用 POINT() 构造函数直接拼字符串？
它不带 SRID 信息，MySQL 8.0 会默认赋予 SRID 0，导致后续所有空间函数（如 ST_Distance_Sphere()）报错或返回无意义结果。更隐蔽的问题是：字段虽能插入成功，但 SPATIAL INDEX 实际失效，查询时退化为全表扫描。
-
POINT(116.372 39.853)❌ 不带 SRID，类型检查松散，索引不可用 -
ST_GeomFromText('POINT(116.372 39.853)', 4326)✅ 显式声明 WGS84 坐标系，触发空间索引生效 - 坐标顺序必须是
POINT(longitude latitude)，写反（如纬度在前）会导致位置偏移到南美洲或南极
批量插入时怎么避免 max_allowed_packet 被截断？
单条 INSERT ... VALUES 拼接太多行，WKT 字符串膨胀快，容易超 MySQL 默认的 4MB 包大小限制。不是调大参数了事，而是要控制单次语句的数据量。
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 每批控制在 500–1000 行以内（视平均坐标长度而定），例如：
INSERT INTO places (...) VALUES (...), (...), ..., (...); - 不要依赖 ORM 自动拼接（如 MyBatis-Plus 的
saveBatch默认 1000 条），需手动分片并确保每片都带ST_GeomFromText(..., 4326) - 若走 JDBC，务必开启
rewriteBatchedStatements=true参数，否则批量只是语法糖，底层仍是 N 次单条提交
事务包裹和索引维护的关键细节
空间索引（SPATIAL INDEX）在大批量插入时会持续更新，拖慢速度。但关掉它再重建又可能丢数据一致性。折中方案是：用事务包住整批，并确认表引擎为 InnoDB。
- 插入前无需
DROP SPATIAL INDEX，InnoDB 支持在线空间索引维护 - 必须用显式事务：
BEGIN; INSERT ...; COMMIT;，避免每行自动提交带来的锁开销和日志刷盘压力 - 确认表定义中
location POINT SRID 4326和索引SPATIAL INDEX(location)的 SRID 严格一致，否则建索引会失败，且错误提示极不友好（只报“Invalid GIS data provided”）
最易被忽略的一点：插入后别急着查距离——先用 SELECT ST_X(location), ST_Y(location) FROM places LIMIT 1; 验证坐标是否真按经度/纬度存进去了。肉眼核对几个点，比跑一遍 ST_Distance_Sphere() 却发现全是 0 米要省半天时间。
