这个项目要把整个会展中心10万平米的展区数字化，每台AR设备每秒上传3组坐标(x,y,z)。最初设计的MongoDB分片方案遇到个致命问题：跨分片的空间查询延迟高达800毫秒，用户体验像在看PPT。后来我们搞了个混合架构：用MySQL的GIS模块存静态展位地图，Redis缓存动态路径，再用消息队列削峰。具体建表时给geometry列加了空间索引：
最精彩的是处理用户实时定位时，我们利用MySQL 8.0的CTE递归查询实现跨展馆最优路径规划。比如用户在A馆想去E馆的展台，系统先用ST_Contains判断当前所在分区，再用ST_Distance_Sphere计算可行路径：
遇到个坑是三维坐标的存储。MySQL的POINT类型只支持二维，我们最后把z轴高度转成属性字段，查询时用ST_MakePoint(x,y)配合height字段做联合筛选。后来发现查询速度下降明显，给(height, geometry)加了个复合索引才解决。
数据归档策略也很有讲究。AR导航产生的轨迹数据七天后价值骤减，但合规要求保留一年。我们按时间分表+分区，热数据放SSD，冷数据转机械盘。每月1号自动用ALTER TABLE EXCHANGE PARTITION把旧数据转移到归档库，这个操作几乎不阻塞实时写入。
现在这套系统撑住了会展高峰期每秒3500次的空间查询，平均响应时间83毫秒。最近运维报表显示最复杂的跨馆导航查询也只用了127毫秒，比当初设计的MongoDB方案快了三倍多。团队里曾经最推崇NoSQL的小王现在天天捧着MySQL空间数据优化的手册啃。
所以别被新技术名词忽悠，老牌数据库在混合现实场景下依然能打。关键是要吃透业务场景，把合适的工具用在合适的环节。下次分享我们怎么用MySQL的JSON字段处理AR设备的动态配置参数，这个玩法更骚。