0

我有一个存储所有客户的特定更新的表。

一些样本表：

record_id | customer_id | unit_id | time_stamp | data1 | data2 | data3 | data4 | more

当我创建应用程序时，我没有意识到这张表会增长多少——目前我在 1 个月内拥有超过 1000 万条记录。当 php 由于花费的时间而停止执行时，我遇到了问题。一些查询会产生前 1个结果，基于time_stamp++customer_idunit_id

您建议如何处理此类问题？例如，我可以为每个客户创建新表，尽管我认为这不是一个好的解决方案。

我一直没有好的解决方案。

4

3 回答 3

1

我建议您按照某些标准对数据进行分区。

您可以对数据进行水平或垂直分区。

例如，使用他的 id 模块 10 将您的 customer_id 分组为 10 个分区。

因此，以 0 结尾的 customer_id 进入分区 0，以 1 结束的进入分区 1

MySQL 可以轻松地为您做到这一点。

于 2013-02-15T02:03:09.690 回答
1

如果您在云上（在服务器和数据库之间移动数据需要付费），请忽略。

将所有逻辑移至服务器

最快的查询是SELECT WHEREing PRIMARY。无论您的数据库有多大，它都会以 1 行表的速度返回（只要您的硬件不失衡）。

我不能确切地告诉你你的查询在做什么，但首先将所有排序和限制数据下载到 PHP 中。一旦你得到了你需要SELECT的东西，数据就会直接WHERE进入record_id（我假设那是你的PRIMARY）。

看起来您的按需数据计算量非常大且非常庞大，因此我建议使用更快的语言。 http://blog.famzah.net/2010/07/01/cpp-vs-python-vs-perl-vs-php-performance-benchmark/

此外，当您开始在服务器而不是数据库上进行排序和限制时，您可以开始识别快捷方式以进一步加快速度。

这就是服务器的用途。

于 2013-02-15T02:24:55.660 回答
0

表中的记录数是多少？通常，对于关系数据库，重要的不是您拥有多少数据（数百万对关系数据库来说不算什么），而是您检索数据的方式。

从你的select来看，其实你可能只需要优化语句本身，避免多次子select，这可能是导致速度变慢的主要原因。尝试对该语句运行解释，或者仅获取 id 并在第一次运行中实际找到并检索的记录的 id 上单独运行内部选择。

仅在您的整体语句中有这些子选择这一事实意味着您还没有在流程中优化到那么远。SELECT gps_unit.idgps_unit例如，您可能正在运行一个每晚或每小时一次的cron 作业，该作业将集合像由表上的飞行。

如果您发现自己无法有效地优化该 select 语句，您可以选择“最终”选项，例如：

  • 通过一些标准进行分类并分成不同的表格。
  • 保留一个深度存档，以便第一年左右的任何内容都迁移到使用较少的表中，并且需要特殊检索。
  • 最后，如果您有如此多的小数据，您可能能够完全归档某些表并仅以文件形式保存它们，然后在某个日期之后截断。通常使用不那么重要且有点垃圾邮件的网络跟踪数据，几年后我最终会这样做，那时数据真的不会再对任何人有任何好处了。
于 2013-02-15T02:02:52.490 回答