数据库每天有40000+条记录

Question

我正在创建一个数据库，用于跟踪南佛罗里达州一个城市的人均用水量。

大约有40000个用户，每个用户都会上传每日读数。

我在想办法设置数据库，让每个用户分开一个表似乎更容易。这样可以简化数据下载，因为服务器不必对包含10百万条目的表进行排序。

我的逻辑是否错误？ 有没有办法索引表名？
有没有其他方法可以设置数据库来提高速度并保持布局足够简单？

- 谢谢你，
贾里德

P.S。 读数的基本数据是：
-locationID（我的想法中的表名）
-Reading
-ReadDate
-ReadTime

p.p.s。在这次谈话中，我上传了5k桌，服务器冻结了。 〜.O
谢谢你的帮助，你好

Answer 1

设置成千上万的表并不是一个好主意。您应该维护一个表并将所有条目放在该表中。 MySQL可以处理大量数据。您将遇到的最大问题是您一次可以处理的查询量，而不是数据库的大小。对于您将要处理数字的情况，请使用属性为int的{​​{1}}，并使用适当大小的unsigned处理文字的实例（除非文字很大，否则使用varchar ）。

处理用户 如果您需要识别用户的记录，请设置另一个可能如下所示的表：

• user_id INT（10）AUTO_INCREMENT UNSIGNED PRIMARY
• name VARCHAR（100）NOT NULL

当您需要将记录链接到用户时，只需引用用户的text即可。对于记录信息，我会设置SQL类似于：

• id INT（10）AUTO_INCREMENT UNSIGNED PRIMARY
• u_id INT（10）UNSIGNED
• 阅读 我不确定你的阅读是什么样的。如果是一个数字，请使用user_id，如果其文字使用INT
• read_time TIMESTAMP

您还可以将阅读的日期和时间合并为VARCHAR。

Answer 2

NOT 为每个用户创建一个单独的表。

在标识用户的列和任何其他常见约束（如日期）上保留索引。

考虑一下最后如何查询数据。你怎么总结一天所有用户的数据呢？

如果您担心主键，我建议保留一个LocationID，Date复合键。

编辑：最后，（我的确意味着这很好）但是如果你问这些关于数据库设计的问题，你确定你有资格参与这个项目吗？看起来你可能已经过了头脑。有时最好知道自己的局限性并让项目通过，而不是以一种为你创造太多工作的方式实现它，人们对结果不满意。再一次，我不是说不要，我只是说你问自己是否可以达到他们期望的水平。似乎有大量用户不断使用它。我想我是说在学习某些事情的同时向数千名用户提供项目可能是一个异常高压的环境。

Answer 3

一般而言，表格应代表一组事物。在您的示例中，您可以轻松识别您拥有的集合：用户和读数;理论上最好的结构就是拥有这两个表，其中读数条目引用了用户的id。

MySQL可以处理非常大量的数据，因此最好的办法是尝试用户读取结构并查看其执行情况。或者，您可能希望查看基于NoSQL数据库的文档，例如MongoDB或CouchDB，因为将读数报告存储为单个文档也是一个不错的选择。

Answer 4

如果您创建一个包含每个用户每月总数的摘要表，那么这肯定是系统的主要用途，对吧？

每个月，您都会对数字进行处理并将总数存储到第二个表中。您可以在滚动的12个月内修剪日志表。也就是说，旧数据可以塞在角落里以保持索引更小，因为当城市被指控欺诈时你只需要访问它。

因此，您存储每日读数的确切方式并非 您需要对此感到非常担忧。给每个用户他自己的桌子不是正确的解决方案。如果你有大量的数据，那么你可能想要通过像MongoDB这样的东西来考虑分片。