获取经纬度信息后，mysql建立数据表po_trajectory，字段包含tra_id、longitude、latitude、tra_time和openid。

为微信小程序创建的 po_trajectory 数据表，字段包含 tra_id、longitude、latitude、tra_time 和 openid，从结构设计上看，对于大数据量的轨迹展示是比较合适的，但需要从多个方面综合考量，下面为你详细分析：

数据表设计合理性

优点

• 主键 tra_id：它可作为数据表的主键，能唯一标识每条轨迹记录，在数据插入、更新、删除操作时能保证数据的完整性和一致性。同时，数据库查询时利用主键进行查询，速度会更快。
• longitude 和 latitude：这两个字段用来存储经纬度信息，是轨迹数据的核心内容。借助它们可以在地图上标记出具体的位置点，进而绘制出轨迹。
• tra_time：该字段记录了轨迹点的采集时间，在展示轨迹时，可依据时间顺序对轨迹点进行排序，从而实现轨迹的动态展示。另外，还能根据时间范围进行数据筛选，提升查询效率。
• openid：此为微信用户的唯一标识，可通过它对不同用户的轨迹数据进行区分和管理，便于多用户场景下的轨迹数据存储和查询。

潜在问题

• 数据类型选择：若 longitude 和 latitude 采用浮点数类型存储，在数据量很大时，可能会占用较多存储空间。可以考虑采用合适的精度进行存储，例如使用 DECIMAL 类型。
• 索引优化：若要对大数据量进行高效查询和分析，需要合理创建索引。例如，可在 openid 和 tra_time 上创建索引，这样能加快按用户和时间范围的查询速度。
• 数据分区：当数据量非常大时，可考虑对数据表进行分区，例如按时间范围进行分区，以提升查询性能。

示例 SQL 代码

下面是创建 po_trajectory 数据表的 SQL 语句，同时包含索引的创建：

-- 创建数据表
CREATE TABLE po_trajectory (tra_id INT AUTO_INCREMENT PRIMARY KEY,longitude DECIMAL(9, 6) NOT NULL,latitude DECIMAL(9, 6) NOT NULL,tra_time DATETIME NOT NULL,openid VARCHAR(32) NOT NULL,INDEX idx_openid (openid),INDEX idx_tra_time (tra_time)
);

代码解释

• DECIMAL(9, 6)：用于存储经纬度信息，精度为小数点后 6 位，能满足大部分地图展示的需求。
• idx_openid 和 idx_tra_time：分别为 openid 和 tra_time 字段创建的索引，可加快按用户和时间范围的查询速度。
• $_POST 中的 longitude 和 latitude 数据，且在向数据库插入数据时，若经纬度小数位数与数据库表字段定义的小数位数不一致，是否会出现问题取决于数据库字段的数据类型和定义。

数据格式

1. 数据库字段为 DECIMAL 类型

如果你在创建数据库表时，将 longitude 和 latitude 字段定义为 DECIMAL 类型，例如 DECIMAL(9, 6)，其含义是总共 9 位数字，其中小数部分占 6 位。

小数位数多于 6 位

当传入的经纬度小数位数多于 6 位时，数据库会进行四舍五入操作。比如，你传入的经度是 116.3971288，数据库会将其存储为 116.397129。

小数位数少于 6 位

若传入的经纬度小数位数少于 6 位，数据库会在小数部分末尾补零。例如，你传入的纬度是 39.9165，数据库会将其存储为 39.916500。

2. 数据库字段为 FLOAT 或 DOUBLE 类型

若数据库字段定义为 FLOAT 或 DOUBLE 类型，这两种类型是浮点类型，存储的是近似值。

小数位数问题

浮点类型通常不会严格限制小数位数，不过可能会存在精度丢失的问题。在处理高精度的经纬度数据时，不建议使用 FLOAT 或 DOUBLE 类型，因为它们可能无法精确存储数据。

总结

总体而言，po_trajectory 数据表的设计对于大数据量的微信小程序轨迹展示是合适的，但需要根据实际的数据量和查询需求进行优化，如合理选择数据类型、创建索引和进行数据分区等。

---

@漏刻有时