当我测试此查询时,大约需要 17 - 20 秒才能完成。
UPDATE ex_hotel_temp
SET specialoffer='1'
WHERE hid IN
(SELECT hid
FROM ex_dates
WHERE offer_id IS NOT NULL
OR xfory_id IS NOT NULL
OR long_id IS NOT NULL
OR early_id IS NOT NULL
GROUP BY hid)
虽然这是一个在晚上运行的 cronjob,用于对数据库进行一些内务处理(没有站点访问者等待结果),但在我看来,这对服务器来说是不可接受的负载。我是对的,还是我无事生非?
当我单独运行查询的每个元素时,大约需要 0.001 秒。因此,我应该将其分解为一系列简单的查询吗?
稍后编辑: 在收到的评论和答案的帮助下,我决定将查询分成两个。结果是这样的:
$query_hotel = "SELECT hid FROM ex_dates WHERE offer_id IS NOT NULL OR xfory_id IS NOT NULL OR long_id IS NOT NULL OR early_id IS NOT NULL GROUP BY hid";
$hotel = mysql_query($query_hotel, $MySQL_XXX) or die(mysql_error());
$row_hotel = mysql_fetch_assoc($hotel);
$totalRows_hotel = mysql_num_rows($hotel);
$hid_array = array();
do {
array_push($hid_array,$row_hotel['hid']);
}while ($row_hotel = mysql_fetch_assoc($hotel)) ;
$hid_list = implode("','",$hid_array);
$hid_list = "'$hid_list'";
// Mark the hotels as having a special offer
$query_update = "UPDATE ex_hotel_temp SET specialoffer='1' WHERE hid IN ($hid_list)";
$result = mysql_query($query_update, $MySQL_XXX) or die(mysql_error());
虽然不漂亮,但很管用。
由于有两个查询包含一些 PHP 代码,我无法准确测量运行时间,但仅通过查看页面加载时间,它显然更接近分数一秒少于 20 秒。
谢谢大家。
你说这在 CRON 作业中运行过夜,并且你说这支持一个“网站” - 如果这是一个面向公众的网站,是的,你应该担心。
互联网上没有营业时间这样的东西——一天中的任何时间都会有访问者与您的网站互动,希望能尝试购买东西;根据我的经验,即使是“国家”网站也往往会看到夜间的流量(尽管与高峰时段相比,流量通常很小)。
您的 CRON 作业也可能导致其他查询运行缓慢 - 这取决于导致查询运行缓慢的原因以及您是否正在使用事务。网站的问题在于,当网站速度缓慢时,用户往往会变得不耐烦,刷新页面,通常会给数据库带来更多流量,并且如果网站上有其他缓慢的查询,则该网站变得无法使用也不是不可能的。有一段时间,即使用户数量相当有限。
因此,如果脚本运行时可能有您网站的用户,那么绝对值得清理。
您可能担心的另一个原因是,根据我的经验,数据库性能不是线性的 - 查询不会与表中的记录数量成线性比例地减慢。相反,它们往往像曲棍球棒一样——一切都很好,直到达到临界点,一切都会停止。您可能正在经历曲棍球棒曲线,并且很容易从 17-20 秒升级到 17-20 分钟。
修复看起来很简单 - 分组依据是多余的,将查询拆分为更小的查询应该有助于子选择使用索引。
我不在乎,只要确保 cron 作业不会在过程中途超时即可。 我个人过去有过查询,然后在 cron 作业中运行了几分钟,没有任何问题。