我有一个表格,可以存储所有客户的特定更新。
一些示例表:
record_id | customer_id | unit_id | time_stamp | data1 | data2 | data3 | data4 | more
当我创建应用程序时,我没有意识到这个表会增长多少 - 目前我在1个月内有超过10mil的记录。我正面临着一些问题,当php由于需要花费的时间而停止执行时。根据{{1}} + time_stamp
+ customer_id
您如何建议处理此类问题?例如,我可以为每个客户创建新表,但我认为这不是一个好的解决方案。
我没有考虑好解决方案。
答案 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
创建的集合聚合到新表中,然后您可以针对以前生成的表而不是创建与运行中的表等效的数据块。
如果您发现自己无法有效优化该选择语句,则可以使用“最终”选项,如: