我正在从事车队管理工作。我在具有以下列的位置表上进行了大量写入
在这里，该表将每 3 秒进行一次写操作。因此，其中将有数百万条记录。因此，为了更快地检索数据，我正在计划分区。现在我的问题：-
将有数万亿的记录
@rc-Thanks man .. 性能如何……看我每 3 秒插入一次数据，所以每次插入数据时我都必须运行一个检查程序……那么性能呢？
2>我想去分区列作为车辆编号.....有没有其他方法...
阅读： MySQL 分区限制
1.) 分区表不支持 FK。
2.) 您用于分区的列将取决于您访问表的方式。如果您的查询始终基于车辆编号，那么在该列上进行哈希分区可能是有意义的。如果您要查询或报告更多关于“本月添加了哪些车辆”之类的内容，或者您想在达到一定年龄时“推出”分区，那么按日期分区可能是要走的路。这是您必须根据您的使用情况来决定的事情。
3.) 有关更多信息，请参阅上面的链接。
根据用户问题进行编辑：
每 3 秒插入一条记录并不是很大的吞吐量。确保您的用户表上有一个主键，以便有效地完成过程内部的检查。（即使支持 FK 也是如此）如果您支持 FK，DB 会在幕后为您执行此检查，因此从这个意义上说，它不会伤害您。如果检查最终成为瓶颈，您可能会觉得需要删除它，并可能将错误的用户 ID 作为夜间批处理报告，但如果您的用户表相对较小且索引正确，我不认为这是一个问题。
另一种选择是使用分区或非分区表手动进行分区（即分片）。当然，对于非分区表，您可以使用本机外键。例如，您可以将您的车辆表拆分为多个表，例如：（假设您想使用 vehicleNo 作为“键”）
车辆数量少于 1000 辆
车辆数量少于 2000 辆
车辆数量少于...
车辆NosLessThanMAX
在这里，您可能希望再次拥有一个 SP，以便应用程序/用户不必了解这些表。SP 将负责根据传入的 vehicleNo 插入/更新正确的表。您还需要一个用于选择数据的 SP，以便应用程序/用户不必知道要从中选择的表。为了轻松访问所有数据，您可以创建一个将所有表联合在一起的视图。
请注意，这样做的一个好处是当前 MyISAM 在更新期间锁定了整个分区表，而不仅仅是它正在更新的分区。以这种方式对表进行分片可以缓解这种争用，因为表本身就是“分区”。
根据我对您正在做的事情的有限数据，我可能会编写 2 个存储过程，1 个用于选择数据，1 个用于更新/插入数据，并让您的应用程序使用这些存储过程进行所有访问。然后我会先尝试通过vehicleNo上的哈希进行常规分区，同时在过程中强制执行user_id键。如果这成为问题，您可以轻松迁移到跨多个表分片数据，而无需更改应用程序，因为有关如何检索和更新数据的所有逻辑都包含在 SP 中。