快速 percona “like” 查询，需要一些解释答案

【问题标题】：Fast percona "like" queries, need some explanation快速 percona “like” 查询，需要一些解释
【发布时间】：2020-02-25 15:16:35
【问题描述】：

我有以下 sql 查询：

select a,b from table left join table2 on ... 
   where
     table.date > (some date) and 
     table.date < (some date) and
     table.first not like '%condition1%' and
     table.first not like '%condition2%' and
     table.first not like '%condition3%' and
     table.first not like '%condition4%' and
     table.first not like '%condition5%'
limit 500 offset 500

“table” - 是一个非常大的分区表，例如在应用日期索引后，我们将获得大约 420 万行来扫描以进一步进行过滤。

所以这个查询运行得非常快——大约 250 毫秒，这怎么可能？我们没有教过不要在大表上以任何方式使用 like，尤其是在双向应用 % 的方式中？

当然还有“table”——在“first”列上没有任何索引。 Percona 版本相当老了 - 5.5.61-38.13。

如何解释这种行为？

【问题讨论】：

标签： mysql percona

【解决方案1】：

好的，我知道了。问题是我的查询缺少“order by”。向此查询添加 order by 可将查询时间提高到 6 秒 - 这现在很有意义。

所以在以前的情况下，mysql 只是在寻找任何与 5 like 模式匹配的数据，而不管排序如何，这现在解释了为什么除了 500 限制偏移之外它工作得如此之快

【讨论】：

【解决方案2】：

我建议您避免使用前导通配符进行 LIKE 搜索。当使用带有前导通配符的类似搜索（例如'%condition1%'）时，数据库将不使用索引。虽然这并不总是一个令人满意的解决方案，但请考虑使用前缀匹配 LIKE 模式（例如 'TERM%'）。

最佳实践示例：

SELECT
  id,
  text
FROM
  tbl
WHERE
  text LIKE 'TERM%';

不良做法示例：

SELECT
  id,
  text
FROM
  tbl
WHERE
  text LIKE '%TERM%';

此外，OFFSET 子句在与高偏移量一起使用时可能会非常慢（例如，在实现分页时使用高页码）。相反，请使用以下 seek 方法，它可以提供更好、更稳定的响应率。

最佳实践示例：

SELECT
  name,
  age,
  department
FROM
  employees
WHERE
  (id, age) > (5000, 40)
ORDER BY
  id,
  age
LIMIT
  10;

不良做法示例：

SELECT
  name,
  age,
  department
from
  employees
where
  age > 40
ORDER BY
  age
LIMIT
  10 OFFSET 5000;

免责声明：我是EverSQL的联合创始人，你可以自动加速你的查询@EverSQL在线SQL优化器

【讨论】：