连接包含 BLOB 的表时 MySQL 查询速度很慢
我有一个带有大量左连接的 MySQL 选择查询,但只有一个连接导致了严重的性能问题。这个麻烦的表中有 2 个 BLOB 字段,当我在其主键上保留连接时,查询的运行时间会增加 20 倍以上。由于这是唯一导致问题的表,我假设 BLOB 与它有关(即使它们没有被选择或连接)。请注意,该表中的行数相对于其他连接表来说并不是特别大。
我怎样才能加快这个查询的速度?
编辑 - 这是查询(有问题的表是“提交”):
SELECT
actions.id,
actions.facebook_id,
actions.created_at,
actions.current_total_points,
actions.current_weekly_points,
submissions.id AS submission_id,
submissions.challenge_week_number AS submission_challenge_week_number,
submissions.challenge_number_in_week AS submission_challenge_number_in_week,
reward_events.id AS reward_event_id,
reward_events.reward_event_type_id,
reward_events.action_id,
reward_events.awarded_badge_type_id,
reward_events.for_week_number AS reward_event_for_week_number,
reward_events.challenge_number_in_week AS reward_event_challenge_number_in_week,
challenge_weeks.week_number
from actions
left join submissions ON submissions.action_id = actions.id
left join reward_events ON reward_events.action_id = actions.id
left join challenge_weeks ON challenge_weeks.start_date <= CAST(actions.created_at AS DATE) AND challenge_weeks.end_date >= CAST(actions.created_at AS DATE)
where actions.facebook_id = '12345678'
order by actions.id asc
这是“提交”表的解释结果:
id bigint(11) unsigned NO PRI auto_increment
action_id bigint(11) NO
title varchar(255) YES
description varchar(255) YES
submission_type enum('alpha','beta','gamma') YES
filename varchar(255) YES
ip_address varchar(255) YES
community_release bit(1) YES
approved bit(1) YES
fullsize longblob YES
thumb longblob YES
modified_at timestamp YES CURRENT_TIMESTAMP
challenge_week_number tinyint(1) YES
challenge_number_in_week tinyint(1) YES
I have a MySQL select query with a large number of left joins, but only one of the joins is causing serious performance problems. This troublesome table has 2 BLOB fields in it, and when I left join on its primary key, the query takes over 20 times as long to run. Since this is the only table causing the problem, I assume that the BLOBs have something to do with it (even though they are not being selected or joined upon). Note that the number of rows in this table is not especially large relative to the other joined tables.
How can I speed up this query?
EDIT - here is the query (the problematic table is "submissions"):
SELECT
actions.id,
actions.facebook_id,
actions.created_at,
actions.current_total_points,
actions.current_weekly_points,
submissions.id AS submission_id,
submissions.challenge_week_number AS submission_challenge_week_number,
submissions.challenge_number_in_week AS submission_challenge_number_in_week,
reward_events.id AS reward_event_id,
reward_events.reward_event_type_id,
reward_events.action_id,
reward_events.awarded_badge_type_id,
reward_events.for_week_number AS reward_event_for_week_number,
reward_events.challenge_number_in_week AS reward_event_challenge_number_in_week,
challenge_weeks.week_number
from actions
left join submissions ON submissions.action_id = actions.id
left join reward_events ON reward_events.action_id = actions.id
left join challenge_weeks ON challenge_weeks.start_date <= CAST(actions.created_at AS DATE) AND challenge_weeks.end_date >= CAST(actions.created_at AS DATE)
where actions.facebook_id = '12345678'
order by actions.id asc
Here is the EXPLAIN result for the "submissions" table:
id bigint(11) unsigned NO PRI auto_increment
action_id bigint(11) NO
title varchar(255) YES
description varchar(255) YES
submission_type enum('alpha','beta','gamma') YES
filename varchar(255) YES
ip_address varchar(255) YES
community_release bit(1) YES
approved bit(1) YES
fullsize longblob YES
thumb longblob YES
modified_at timestamp YES CURRENT_TIMESTAMP
challenge_week_number tinyint(1) YES
challenge_number_in_week tinyint(1) YES
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您是否尝试过在要加入的非 PK 字段(例如
submissions.action_id
和reward_events.action_id
)上创建索引?这应该会导致查询时间的减少与您要加入的表的大小成正比。Have you tried creating indexes on the non-PK fields that you're joining on, like
submissions.action_id
andreward_events.action_id
? That should result in decreases in query time proportional to the size of the tables that you're joining on.