【问题标题】:How to optimize SELECT against a constant value?如何针对恒定值优化 SELECT?
【发布时间】:2015-11-19 05:53:22
【问题描述】:

因为我使用了我无法控制的数据结构,所以我的数据库中有一个表,其中可能包含数百万个 Foreign-key => (key => value) 对。现在,我知道其中一个键将是某个值(在这种情况下,键是related_content)。 MySQL 是否可以优化查询,使其不必在整个表中搜索结果?

示例表(称为meta):

fk | key               | value
====================================
1  | 'related_content' | '[2,3,4]'
1  | 'condiment'       | 'mayo'
1  | 'condiment'       | 'bananas'
29 | 'condiment'       | 'ketchup'
29 | 'related_content' | '[1,7,9]'
95 | 'condiment'       | 'mustard'
95 | 'related_content' | '[5,6,8]'

查询示例:

SELECT value FROM meta WHERE fk = 29 AND key = 'related_content';

我想做的是:

ALTER TABLE `meta` ADD INDEX `meta_related` ON (`key`) WHERE `key` = 'related_content';

(在有人问之前,key 列上已经有索引)

【问题讨论】:

  • 如果您已经拥有key 上的密钥,为什么您认为另一个会有帮助?为什么需要它 - 它很慢吗?
  • 由于key = related_content 的内容集比完整内容要小得多,因此似乎拥有一个专门的、单独的索引会更快。
  • 如果使用密钥,它应该是超快的,可能无法再加速了。不知道将密钥更改为 desc 订单是否有任何好处 - 我对此表示怀疑。
  • 至于“它慢吗”,答案是“暂时不”。这是一个在尝试另一个连接之前需要查询的值。 (基本上这张表是存储user的内容,我们需要判断是否需要使用自动化流程。由于数据是如何序列化的,我们需要将初始查询的结果返回给客户端在创建新查询之前使用语言。我们可以做的任何事情来优化该时间都是最好的)。
  • 这是您对匹配相关内容的子集进行分配操作的原因吗?可能您可以先构建一个仅包含相关内容行的临时表?完成初始选择后,您就可以为所有其他操作准备好正确的设置了。

标签: mysql indexing where


【解决方案1】:

添加“复合”索引

 INDEX(fk, key)

【讨论】:

    【解决方案2】:

    如果您要添加 key_index (int11) 列来表示键列中的字符串,例如:related_content =1, condiment=2,并且您将在 key_index 列上添加索引,那么 int 上的索引将比 on 更快字符串,最后您将使用两个索引整数字段进行选择。会很快的

    【讨论】:

      猜你喜欢
      • 2011-08-01
      • 2023-01-12
      • 2015-04-01
      • 2010-09-13
      • 1970-01-01
      • 2011-05-14
      • 1970-01-01
      • 2018-05-10
      • 1970-01-01
      相关资源
      最近更新 更多