【问题标题】:Is MySQL automatically optimizing my repeat queries?MySQL 会自动优化我的重复查询吗?
【发布时间】:2016-12-13 05:18:01
【问题描述】:

在我的数据库上测试查询速度时,我注意到了一些特殊情况。我有两个问题。

SELECT * 
FROM  `event_history` 
WHERE  `event_details` LIKE  '%joe submitted order%'

SELECT * 
FROM  `event_history` 
WHERE  `event_details` LIKE  '%bob submitted order%'

第一个由应用程序频繁运行。第二个是我刚刚手动运行一次的东西。我注意到第一个只跑了 0.0035 秒,但第二个花了大约 0.2500 秒。这是意料之外的。

MySQL 是否以某种方式优化了这个查询?如果是这样,我该如何配置它,比如在将第二个查询投入生产之前对其进行优化?

【问题讨论】:

  • 没有进行这样的优化。但是,如果您自己没有优化查询/数据库结构,可能会有很大的不同。因此,如果您没有在查询中使用的列上设置正确的索引。这可以很好地解释看似相同的查询中的差异。
  • @arkascha 这是一个简单的表,带有递增的 id 主索引。
  • 这意味着您的索引没有设置正确。由于您通过event_details 列进行选择,因此您绝对应该为该列创建索引!您还应该考虑到LIKE 操作符与所有其他选项相比非常慢。真的没有办法绕过这么昂贵的查询吗?
  • 哦,其实我才意识到MySQL实现了查询结果缓存!这当然可以解释你所看到的。看这里:dev.mysql.com/doc/refman/5.7/en/query-cache.html
  • @arkascha 我知道一起避免 LIKE 会更理想,但不是一种选择。所以我可以为我选择的文本列创建索引吗?我应该使用“FULLTEXT”索引吗?

标签: mysql sql optimization query-optimization


【解决方案1】:

MySQL 实现了查询结果缓存。这当然可以解释您所看到的,因为您报告经常运行的查询比您第一次执行的查询返回得更快。

查看详情: http://dev.mysql.com/doc/refman/5.7/en/query-cache.html

【讨论】:

  • 大多数生产系统最好禁用 QC。 对表的每次修改都会从 QC 中删除该表的所有项。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多