0

我最近注意到我的一个查询运行得很慢，每个查询几乎 1 秒。

查询看起来像这样

选择事件日期.id，
        事件日期.eid,
        事件日期.日期，
        事件日期.时间，
        事件日期.title,
        eventdate.address,
        eventdate.rank,
        事件日期.city,
        事件日期.state,
        事件日期名称，
        来源.链接，
        类型，
        事件日期.img
来源
右外连接
(
    选择事件.id，
            活动日期，
            用户名，  
            用户排名，
            用户.eid,
            事件地址，
            事件.城市，
            事件状态，
            事件.lat,
            事件。`long`,
            GROUP_CONCAT(types.type SEPARATOR ' | ') AS 类型
    FROM 事件 FORCE INDEX (latlong_idx)
    在 event.uid = users.id 上加入用户
    在 users.tid=types.id 上加入类型
    在 -74.36829174058 和 -73.64365405942 之间的“长”
    和 40.35195025942 和 41.07658794058 之间的纬度
    AND event.date >= '2009-10-15'
    GROUP BY event.id, event.date
    ORDER BY event.date, users.rank DESC
    限制 0, 20
）活动日期
ON eventdate.uid = source.uid
AND eventdate.date = source.date;

解释是

+----+-------------+------------+--------+-------- --------+--------------+---------+------------------ ------------+--------+----------------------------- ----+
| 编号 | 选择类型 | 表| 类型 | 可能的键 | 关键 | key_len | 参考 | 行 | 额外 |
+----+-------------+------------+--------+-------- --------+--------------+---------+------------------ ------------+--------+----------------------------- ----+
| 1 | 初级 | | 全部 | 空 | 空 | 空 | 空 | 20 | |
| 1 | 初级 | 来源 | 参考 | iddate_idx | iddate_idx | 7 | 事件日期.id,事件日期.日期 | 156 | |
| 2 | 派生 | 活动 | 全部 | latlong_idx | 空 | 空 | 空 | 19500 | 使用临时的；使用文件排序 |
| 2 | 派生 | 类型 | 参考 | eid_idx | eid_idx | 4 | 活动.event.id | 10674 | 使用索引 |
| 2 | 派生 | 用户 | eq_ref | id_idx | id_idx | 4 | active.types.id | 1 | 使用位置 |
+----+-------------+------------+--------+-------- --------+--------------+---------+------------------ ------------+--------+----------------------------- ----+

我曾尝试在 latlong 上使用“力指数”，但这似乎并没有加快速度。

是导致响应缓慢的派生表吗？如果是这样，有没有办法提高这个性能？

--------编辑------------- 我也尝试改进格式以使其更具可读性

我运行相同的查询，仅将 'WHERE 语句更改为

WHERE users.id = (
选择用户.id
来自用户
WHERE uidname = 'frankt1'
ORDER BY users.approved DESC , users.rank DESC
限制 1)
AND日期> = '2009-10-15'
按日期分组
按日期订购）

该查询在 0.006 秒内运行

解释看起来像

+----+-------------+------------+-------+--------- ------+----------------+---------+------ -------------+------+----------------+
| 编号 | 选择类型 | 表| 类型 | 可能的键 | 关键 | key_len | 参考 | 行 | 额外 |
+----+-------------+------------+-------+--------- ------+----------------+---------+------ -------------+------+----------------+
| 1 | 初级 | | 全部 | 空 | 空 | 空 | 空 | 42 | |
| 1 | 初级 | 来源 | 参考 | iddate_idx | iddate_idx | 7 | 事件日期.id,事件日期.日期 | 156 | |
| 2 | 派生 | 用户 | 常量 | id_idx | id_idx | 4 | | 1 | |
| 2 | 派生 | 活动 | 范围 | eiddate_idx | eiddate_idx | 7 | 空 | 24 | 使用位置 |
| 2 | 派生 | 类型 | 参考 | eid_idx | eid_idx | 4 | 活动.event.bid | 3 | 使用索引 |
| 3 | 子查询 | 用户 | 全部 | idname_idx | idname_idx | 第767章 | 5 | 使用文件排序 |
+----+-------------+------------+-------+--------- ------+----------------+---------+------ -------------+------+----------------+
4

1 回答 1

1

清理那个庞大的 SQL 语句的唯一方法是回到绘图板上，仔细研究您的数据库设计和要求。一旦您开始加入 6 个表并使用内部选择，您应该会期待难以置信的执行时间。

首先，确保您的所有 id 字段都已编入索引，但最好确保您的设计有效。我不知道从哪里开始查看您的 SQL - 即使在我为您重新格式化之后。

请注意，“使用索引”意味着您需要在创建或更改正在使用的表时发出正确的指令。参见例如MySql 5.0 创建索引

于 2009-10-15T23:47:25.873 回答