@Allenxup 那你得自己验证下了，思路：
1 ，硬盘速度跟上，看下磁盘队列有没有占满或者拉长
2 ，sql 索引使用情况，比如我早期版本关系型数据库，天然就给查询只提供一种方式，一定会命中索引
3 ，sql 一次读取量大小，sql 查询效率之外，那就是看你数据从硬盘到内存的总大小是不是满速传输依然需要 6 秒了，可以根据需要缩减需要返回的字段数量
4 ，其他处理，有没有额外在程序里过滤或者排序，或者替换补充数据等等，能回归到原始的硬盘读写，就不要去费劲转换
5 ，网络传输，服务器到客户端经过的网络带宽跟你序列化之后的结果集大小换算下耗时

@Allenxup 我建议是放在后端，这样可以用额外的 webapi 去进行处理，前端只管使用数据成果即可。
我之前是同时存储 2 份数据，这样遇到比如计算里程的时候，直接使用原始坐标可以更高的理论准确度。实际用下来却发现意义不大，虽然两套标准并没有线性关系，但是在较多点的场景下，互相填补之后的里程计算结果基本就接近均匀坐标了

@mineralsalt 差别还是有的，我 oracle 上宝塔跑分 2500 不到，阿里轻量可以 8000 多

腾讯也就靠绝版无忧，阿里也就靠 hk24 元机器

hk 24 可能是最实惠的了

中途找地方，离开高速充电问题不大

长期耳鸣患者表示，除了适应共存，几乎没别的办法

检查：可疑网络链接，可疑进程，可疑文件，可疑脚本任务

去农村赶集

找加油站啊

不知道是不是同一种因素，在比较累的时候有过，而且伴随着大幅度张闭口时候崩的那种感觉，大睡一觉好了

@g18638715723 搜下关键字：平板模式，相当于盖上了盖子，手机和平板电脑会有这个设计，就是利用磁性感知皮套的

@Allenxup 历史轨迹单独存，这张表很大，但用途非常单一，仅仅用于需要使用历史数据的场景，结构也足够简单，仅仅支持单设备特定时间查询，仅仅支持写入效率，就已经足够了
nosql 的我没写，参考下我之前关系型结构的博客： https://www.opengps.cn/Blog/View.aspx?id=284

smtp?

“177cm 身高，体重 62.5kg”我觉得这个很健康的啊

这也不多，我曾经在关系型里都能存到几十亿条，你这非关系型问题更不大了
有一点需要调整：查询最新位置没必要进入历史表，用缓存或者单独一个表去更新存储最新即可。

车险监管非常严格，所以完全可以选便宜的，主要是附加福利少了些，比如免费的送油，免费的拖车，免费的 xx 、
其他方面的问题是：出问题到场时长变长、审核流畅变慢，没有小程序小案值快捷自助报案之类

考虑下磁力，我之前的老笔记本联想 Y460 ，当有磁铁从屏幕低下划过一定会关机。
然后我同事不信邪，那他的 T 本试了下，结果整个系统废了