Mysql 加快SQL查询速度，已经奏效了

我有这个问题

SELECT distinct(season) as seasons,
        s.name as seriename,
        c.content_digest,
        c.sub_category_id,
        c.source_url,
        c.synopsis,
        c.short_synopsis,
        c.title,
        c.duration,
        c.subtitle_url,
        c.logo_url,
        c.provider_id,
        c.event_date,
        c.start_time,
        c.live,
        c.seriesid as cSerieId,
        c.episode,
        c.season,
        c.content_id FROM content c
        INNER JOIN provider ON provider.id = c.provider_id
        LEFT OUTER JOIN serie s ON s.seriesid = c.seriesid
        WHERE live = '0' AND c.version >= provider.version
        ORDER BY seriename DESC, title
        DESC
        LIMIT 0, 18446744073709551615;

它已被编入索引并进行了一定程度的优化，以快速交付结果（它在0.3秒内交付了44000行）。 不知什么原因，磨我的齿轮，它不再是0.3秒快，它的2.5秒快

下面是对上述SQL的解释

1   SIMPLE  provider    index   PRIMARY,provider_id_idx,provider_version_idx    provider_version_idx    5       16  Using index; Using temporary; Using filesort

1   SIMPLE  c   ref c_providerid_idx,c_live_idx,c_version_idx   c_providerid_idx    5   provider.id 3179    Using where

1   SIMPLE  s   ref seriesid_idx    seriesid_idx    97  c.seriesid  1   

据我所知，它正在使用它的索引，但仍然是2.5秒。。 我已经在谷歌上搜索了查询缓存，激活了它，试图调整它，但仍然需要2.5秒

有什么建议吗？ 如果你需要，我会发布更多信息

最终结果

SELECT s.name as seriename, 
            c.season as seasons,
            c.content_digest,
            c.sub_category_id,
            c.source_url,
            c.synopsis,
            c.short_synopsis,
            c.title,
            c.duration,
            c.subtitle_url,
            c.logo_url,
            c.provider_id,
            c.event_date,
            c.start_time,
            c.live,
            c.seriesid as cSerieId,
            c.episode,
            c.season,
            c.content_id FROM content c
            INNER JOIN provider ON provider.id = c.provider_id
            LEFT OUTER JOIN serie s ON s.seriesid = c.seriesid
            WHERE live = '0' AND c.version >= provider.version
            GROUP BY (CASE WHEN ( seriename IS NOT NULL )
            THEN seriename ELSE title END) 
            ORDER BY seriename DESC, title DESC
            LIMIT 0, 50

---

根据服务器的负载和数据集的大小，请求的时间可能会有所不同

我不确定，但它有时会带来不同，将

c.version>=provider.version

与join一起带来，而不是在

WHERE

中。请参阅下面的完整查询。让我知道

解释
结果

SELECT distinct(season) as seasons,
    s.name as seriename,
    c.content_digest,
    c.sub_category_id,
    c.source_url,
    c.synopsis,
    c.short_synopsis,
    c.title,
    c.duration,
    c.subtitle_url,
    c.logo_url,
    c.provider_id,
    c.event_date,
    c.start_time,
    c.live,
    c.seriesid as cSerieId,
    c.episode,
    c.season,
    c.content_id FROM content c
    INNER JOIN provider ON provider.id = c.provider_id 
    AND c.version >= provider.version
    LEFT OUTER JOIN serie s ON s.seriesid = c.seriesid
    WHERE live = '0' 
    ORDER BY seriename DESC, title
    DESC
    LIMIT 0, 18446744073709551615;

还可以为
内容
表中的
（version，live，id）
列创建复合（多列）索引。以下是创建多列索引的查询：
ALTER TABLE content ADD INDEX idxc\u vr\u lv\u id（version，live，id）
这是你的问题：它工作得太慢了！事实上，你在序列号和标题字段上没有索引，因为我知道你改变了查询？或者有一天它变慢了。你为什么在19列上做一个
DISTINCT
，有实际的重复吗？为什么会有那个愚蠢的限制？@N.Molderf，我有关于序列号和标题的索引，有没有线索说明为什么不使用它们？juergend，实际上没有什么变化，我是认真的：/d不过，我会重新考虑使用distinct。限制是因为我想输出所有的行，而不仅仅是0,30或01000。。。我读到1844年。。。是最大值，因此我使用了ITI如果您想返回所有行，只需省略
限制
#id，选择类型、表、类型、可能的键、键、键、列、参考、行、额外的“1”、“简单”、“提供程序”、“索引”、“主要”、“提供程序id”、“提供程序版本idx”、“提供程序版本idx”、“5”、“空”、“16”、“使用索引”；使用临时设备；使用文件排序“1”、“SIMPLE”、“c”、“ref”、“c\u providerid\u idx、c\u live\u idx、c\u version\u idx”、“c\u providerid\u idx”、“5”、“provider.id”、“3695”、“使用where”“1”、“SIMPLE”、“s”、“ref”、“seriesid\u idx”、“seriesid\u idx”、“97”、“c.seriesid”、“1”，不认为它已具体更改表中的
live
列？由于查询“c.live”不清楚，内容作为cOkay也接受c.live加入条件，而不是将其保留在where子句中。然后再次发布解释。这肯定会提高性能创建一个
（version，live，id）
列的复合索引。