我正在制作一个汽车跟踪系统，我想把每辆车每5秒钟发送的数据存储在mysql数据库中。假设我有1000辆车在5秒后将数据传输到我的系统，并且数据存储在一个表中。在某个时候，我想查询这个表以生成特定车辆的报告。我混淆了是将所有车辆数据记录在一个表中，还是为每辆车创建一个表（1000个表）。哪个更有效？
wh6knrhe1#
一张table，不是每辆车一张table。当您试图备份或维护一个有1000个表的数据库时，它将成为一个垃圾箱。尽可能地缩短表中的行；它会有很多记录。在timestamp和on（car\u id，timestamp）上索引该表。第二个索引将允许您高效地报告单个汽车。阅读https://use-the-index-luke.com/
zhte4eai2#
这是“冰山一角”。这里和dba.stackexchange上大约有5个线程与跟踪汽车/卡车有关。下面是一些进一步的提示。使数据类型尽可能小。您的表将变得巨大--可能会导致磁盘溢出，并且由于“大行意味着可以在ram中缓存的行更少”而减慢查询速度。对于一辆整夜闲置的汽车，你是否保留了“相同”的信息？想想这会占用多少磁盘空间。如果您使用的是hdd磁盘，请选择100 INSERTs /其次，在你需要重新设计摄入过程之前(有一些技术可以给你10倍，也许100倍，但你必须应用它们。你会让几个服务器收集数据，然后简单地插入数据库吗？我的观点是，这可能是你的第一个瓶颈。 PRIMARY KEY(car_id, ...) 因此，访问一辆车的数据是有效的。今天，你说这些数据将永远保存。但是你计算过你的磁盘需要多大吗？大幅缩减数据的一种方法是，在一个月后，将“旧”数据合并为1分钟的时间间隔。开始考虑你想保留什么。例如：最小/最大/平均速度，而不仅仅是瞬时速度。当发生任何重大变化时有额外记录（发动机打开；发动机关闭；安全气囊展开；等）（我可能有更多的建议。）
INSERTs
PRIMARY KEY(car_id, ...)
n3schb8v3#
正常每天86400秒/5=17280条记录/辆车和每天。每天将产生1728万条记录。一般来说，这不是mysql的问题。一个设计好的表很容易查询。如果你为每辆车买一张table，那就是，将来什么时候会有2000辆车。但问题也在于：您希望将数据存储多长时间？当您的数据库是200GB、800gb、2tb时，计算起来很容易，。。。。
3条答案
按热度按时间wh6knrhe1#
一张table，不是每辆车一张table。当您试图备份或维护一个有1000个表的数据库时，它将成为一个垃圾箱。
尽可能地缩短表中的行；它会有很多记录。
在timestamp和on（car\u id，timestamp）上索引该表。第二个索引将允许您高效地报告单个汽车。
阅读https://use-the-index-luke.com/
zhte4eai2#
这是“冰山一角”。这里和dba.stackexchange上大约有5个线程与跟踪汽车/卡车有关。下面是一些进一步的提示。
使数据类型尽可能小。您的表将变得巨大--可能会导致磁盘溢出，并且由于“大行意味着可以在ram中缓存的行更少”而减慢查询速度。
对于一辆整夜闲置的汽车，你是否保留了“相同”的信息？想想这会占用多少磁盘空间。
如果您使用的是hdd磁盘，请选择100
INSERTs/其次，在你需要重新设计摄入过程之前(有一些技术可以给你10倍，也许100倍，但你必须应用它们。你会让几个服务器收集数据，然后简单地插入数据库吗？我的观点是，这可能是你的第一个瓶颈。
PRIMARY KEY(car_id, ...)因此，访问一辆车的数据是有效的。今天，你说这些数据将永远保存。但是你计算过你的磁盘需要多大吗？
大幅缩减数据的一种方法是，在一个月后，将“旧”数据合并为1分钟的时间间隔。开始考虑你想保留什么。例如：最小/最大/平均速度，而不仅仅是瞬时速度。当发生任何重大变化时有额外记录（发动机打开；发动机关闭；安全气囊展开；等）
（我可能有更多的建议。）
n3schb8v3#
正常每天86400秒/5=17280条记录/辆车和每天。每天将产生1728万条记录。一般来说，这不是mysql的问题。一个设计好的表很容易查询。如果你为每辆车买一张table，那就是，将来什么时候会有2000辆车。但问题也在于：您希望将数据存储多长时间？当您的数据库是200GB、800gb、2tb时，计算起来很容易，。。。。