mysql - 怎么可能有一个好的 EXPLAIN 和一个慢查询？

Question

怎么可能像下面这样在 EXPLAIN 中有一个好的计划并有一个缓慢的查询。几行，使用索引，没有文件排序。

查询在 9 秒内运行。主表有大约 50 万行。

当我在该表中有 25 万行时，查询在 < 1 秒内运行。

有什么建议吗？

查询(1. 可以根据用户选择启用注释的字段。2. 没有 FORCE INDEX 我得到 14s。3. SQL_NO_CACHE 我用来防止错误结果):

    SELECT SQL_NO_CACHE
          p.property_id
        , lct.loc_city_name_pt
        , lc.loc_community_name_pt
        , lc.loc_community_image_num_default
        , lc.loc_community_gmap_longitude
        , lc.loc_community_gmap_latitude
    FROM property as p FORCE INDEX (ix_order_by_perf)
    INNER JOIN loc_community lc 
        ON lc.loc_community_id = p.property_loc_community_id
    INNER JOIN loc_city lct FORCE INDEX (loc_city_id)
        ON lct.loc_city_id = lc.loc_community_loc_city_id
    INNER JOIN property_attribute pa
        ON pa.property_attribute_property_id = p.property_id        
    WHERE p.property_published = 1
        AND (p.property_property_type_id = '1' AND p.property_property_type_sale_id = '1') 
        AND p.property_property_housing_id = '1' 
--      AND p.property_loc_community_id = '36'  
--      AND p.property_bedroom_id = '2'
--      AND p.property_price >= '50000' AND p.property_price <= '150000'
--      AND lct.loc_city_id = '1'
--      AND p.property_loc_subcommunity_id IN(7,8,12) 
    ORDER BY 
          p.property_featured DESC
        , p.property_ranking_date DESC
        , p.property_ranking_total DESC
    LIMIT 0, 15

查询配置文件

结果集始终输出 15 行。但是表属性和 property_attribute 有大约 50 万行。

谢谢大家

阿曼多·米亚尼

Answer 1

在这种情况下，这似乎确实是 EXPLAIN 中的一个奇怪之处。这不会发生在 MySQL 4.x 上，但会发生在 MySQL 5.x 上。

MySQL 真正向您展示的是 MySQL 正在尝试使用强制索引 ix_order_by_perf 对行进行排序，它向您显示 15 行，因为您有 LIMIT 15。

但是，WHERE 子句仍在扫描所有 500K 行，因为它无法将索引用于 WHERE 子句中的条件。如果它能够使用索引来查找所需的行，您会看到“possible_keys”字段中列出的强制索引。

您可以通过保留 FORCE INDEX 子句并删除 ORDER BY 子句来证明这一点。您会看到 MySQL 现在不会使用任何索引，即使是您强制使用的索引(因为索引不能用于此目的)。

尝试将 property_property_type_id、property_property_type_sale_id、property_property_housing_id 以及您在 WHERE 子句中引用的任何其他列添加到索引的开头。