查询优化（MySql/Sql）：将函数移出 where 子句

Question

更新：对于阅读本文的任何人，正如@dnoeth 所述，索引在查询时间方面会产生巨大的差异。在某些情况下，它将行扫描减少到 1 行。您只需选择最适合您的索引风格。 Clustered vs Non Clustered

索引示例：

E.g: create index ix_descr on my_db.media (description asc)

---

我有一个查询需要很长时间才能运行，它在 where 子句中有很多函数。优化查询的最佳方法是什么？

将函数移出 where 子句并用连接等替换它们？

我在下面给出了几个简单的例子，FIG 2和3是我的优化尝试，让我知道你的想法。

注意*这些不是我实际使用的函数，我使用 dbo.DecryptBlob(m.mediaId) 等。我选择使用下面的函数以使问题更容易掌握。

图 1.)

SELECT 
    description, id
FROM
    my_db.media
where 
    length(description) = 10
    and description like "S%"
    and trim(left(m.description,2)) = 'St'

---

可能的优化

图 2.)（使用 join 和 group by）

SELECT
    m.description, m.mediaId
FROM
    my_db.media m
        inner JOIN
    my_db.media m1 ON length(m.description) = 10 
        and m.description like "S%"
        and trim(left(m.description,2)) = 'St'
group by m.mediaId

图 3.)（使用连接和区分）

SELECT distinct
    m.description, m.mediaId
FROM
    my_db.media m
        inner JOIN
    my_db.media m1 ON length(m.description) = 10 
        and m.description like "S%"
        and trim(left(m.description,2)) = 'St'

Answer 1

您的起始评论我将其表述为“不要在函数内隐藏索引列，优化器找不到它以使用 INDEX。”

and description like "S%"
and trim(left(m.description,2)) = 'St'

和

一样

and description LIKE "St%"

这样，INDEX(description) 就会很好地工作。检查 length=10 是次要的，并不是真正的问题。它将对该索引进行“范围”扫描。 （如果您不是指“2”和“St”，那么我的评论可能不适用。）

TRIM -- 清理输入，而不是在SELECT 期间尝试这样做。

在这种情况下，使用JOIN 将显示内容。

在SELECT 列表中未指定mediaId 时执行group by m.mediaId 是“错误的”。所以，我不知道你在图2中的目标是什么。

Answer 2

如果您的应用程序经常根据描述的长度进行选择，您应该考虑添加一个包含描述长度的列并在其上创建索引。