gps系统内的历史轨迹表
需要存储的字段有ID、车牌、时间、经度、纬度、地址、里程
要求能够查询自定义时间内的轨迹信息、常用停车热点分析
数据库的表要如何优化，才能让查询效率大大提高。
你的问题好比问，我要让我的马车日行万里，请问怎么改进马车。
首先你要明白的是，马车再怎么优化，也做不到，你需要的是火箭。
一样的道理，你需要的不是数据库的表怎么优化，因为优化来优化去，都不可能处理这样海量的数据。
你应该把你的思维和眼界放在群集和并行化的架构上，考虑map-reduce（分布化多机化你的架构，这个叫做map，将并行查询的结果汇总、规约，叫做reduce）的方案。
主要是要根据查询条件，设置对应的索引，这个可以比较好的提升效率，然后就是多看看explain执行计划，分析瓶颈
用HBase，高并发，实时读写，伸缩性好
同行啊，首先查询的时候以索引作为查询条件是必须的，另外建议采用数据库轨迹表采用分表存储。
摸清数据产生量如何，如果是1钞钟1条记录，则一台车一天就有86400条记录，则建议如下：
1、每台车使用单独的表，程序内部使用CreateTable，动态创建表，销毁表。这样车与车之间不会产生联系。
前提：系统管理的车应该不会经常变来变去，没有很多关联查询出多台车轨迹的需求。
2、建立当前表、历史表、统计表
当前表：仅存储当天的记录。表的个数为=车数量，记录条数小于10万条。
这样不管条数有多少，系统的插入等工作的正常运行不会受到任何影响。
历史表：有12个历史表，每个表存储一个月的历史信息，也即最多保留一年的明细记录。表的个数=车数量 * 12
每天凌晨可以进行当前表的过期记录的转移、删除工作。这样每个表的条数约250万条。使用好点的服务器，还免强能接受了。
统计表：将明细记录按一定的周期（如每半小时一条）进行压缩统计，存储进入统计表。供查询统计使用。
根据你们的具体需求，可以将数据按以上三种方法组合。如可以建立统计周期为分钟、10分钟、1小时、1天等等的各种表。
统计周期越短，保存的时期越短，查询得越清晰。也即查询时越靠近当前查询得越清晰。
redis数据库可以用
我说千万或者亿级数据对现在的数据库来说不算大好不？ 简单说，两种简单方式：
hot data in memory
就是说，建立一个自己的Hot pool，然后放内存里，用内存库来解决这部分的数据速度
cold data using cluster
对于cold data， 要看你的资源情况，如果存储的处理资源足够，那么依靠合适的索引也没问题，如果资源不够，那么用MR
mysql的优势在于可以加入secondary index以及oltp ，劣势在于容量和计算量都有限无法随意扩展。
hbase的劣势在于不支持secondary 仅支持一个大的primary id ，不支持事务，基本上决定了hbase没有法子用于服务关系类的在线业务，优势在于容量无限扩展且自带容灾
mongo 单机有二级索引，无事务，可以sharding但是存储层和计算层不分离
结论1.容量需求大，非实时分析，选用hbase
2.在线oltp类业务采用mysql
3.一些带有明显primary key的业务 但在内部查询时有需要二级索引做过滤条件的，选择mongo或mysql sharding，前者易搭建，后者更服务健壮
作者：知乎用户
链接：https://www.zhihu.com/question/26518864/answer/236432748
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
针对这种大量数据可以尝试建立索引和分区