如何接近数百万的数据选择

时间:2013-02-15 01:55:10

标签: php mysql database-performance

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

一些示例表:

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

当我创建应用程序时,我没有意识到这个表会增长多少 - 目前我在1个月内有超过10mil的记录。我正面临着一些问题,当php由于需要花费的时间而停止执行时。根据{{​​1}} + time_stamp + customer_id

,某些查询会产生前1个结果

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

我没有考虑好解决方案。

3 个答案:

答案 0 :(得分:1)

我建议您按照某些标准使用数据分区。

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

例如,使用他的id模块10将您的customer_id分组到10个分区中。

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

MySQL can make this轻松为您服务。

答案 1 :(得分:1)

如果你在云上(在服务器和数据库之间移动数据的费用),请忽略。

将所有逻辑移至服务器

最快的查询是SELECT WHERE PRIMARY。无论数据库有多大,它都会以1行表的速度快速返回(只要您的硬件不平衡)。

我无法确切地说出你在查询中做了什么,但首先将所有排序和限制数据下载到PHP中。获得所需内容后,SELECT直接WHERE数据record_id PRIMARY(我认为这是您的{{1}})。

看起来你的随需应变数据计算密集且数量巨大,所以我推荐使用更快的语言。 http://blog.famzah.net/2010/07/01/cpp-vs-python-vs-perl-vs-php-performance-benchmark/

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

这就是服务器的用途。

答案 2 :(得分:0)

表格中的记录数量是多少?通常,对于关系数据库,并不是您拥有多少数据(数百万对关系数据库没有任何意义),而是您正在检索它的方式。

从你的选择看,实际上,你可能只需要优化语句本身并避免多个子选择,这可能是减速的主要原因。尝试在该语句上运行解释,或者只是获取id并在您实际找到的记录的id上单独运行内部选择&在第一次运行中检索。

事实上,在整个声明中包含这些子选择意味着您还没有优化过程。例如,您可以运行一个夜间或每小时的cron作业,该作业将SELECT gps_unit.idgps_unit创建的集合聚合到新表中,然后您可以针对以前生成的表而不是创建与运行中的表等效的数据块。

如果您发现自己无法有效优化该选择语句,则可以使用“最终”选项,如:

  • 通过某些标准进行分类并拆分为不同的表格。
  • 保留一个深层存档,以便将第一年左右的任何内容迁移到较少使用的表格并需要特殊检索。
  • 最后,如果您有这么多小数据,您可以完全归档某些表并仅以文件形式保存它们,然后截断某个特定日期。通常网络跟踪数据并不重要且有点垃圾,我最终会在几年之后这样做,当时数据真的不再对任何人有任何好处了。