【问题标题】:Why is MySQL showing index_merge on this query?为什么 MySQL 在此查询中显示 index_merge?
【发布时间】:2013-04-23 09:41:55
【问题描述】:

我有一个看起来相当简单的表结构,但是 MySQL 在简单查询中默认为不太理想的index_merge

这是表结构:

CREATE TABLE IF NOT EXISTS `event_log` (
  `event_id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(5) DEFAULT NULL,
  `location_id` int(10) DEFAULT NULL,
  `object_id` int(5) DEFAULT NULL,
  `action_id` int(5) DEFAULT NULL,
  `date_event` datetime DEFAULT NULL,
  PRIMARY KEY (`event_id`),
  KEY `user_id` (`user_id`),
  KEY `date_event` (`date_event`),
  KEY `action_id` (`action_id`),
  KEY `object_id` (`object_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1;

解释一个基本的 SELECT 查询

EXPLAIN SELECT date_event
FROM event_log
WHERE user_id =123
AND object_id =456
AND location_id =789 

返回:

select_type  table     type         possible_keys       key                 key_len     ref     rows    Extra
SIMPLE       event_log index_merge  user_id,object_id   object_id,user_id   5,5         NULL    27      Using intersect(object_id,user_id); Using where

为了便于阅读,这里是额外的部分:

Using intersect(object_id,user_id); Using where

为什么 MySQL 没有在这个查询中使用标准索引?为什么它与user_idobject_id 相交?

【问题讨论】:

    标签: mysql indexing query-optimization explain


    【解决方案1】:

    查询的最有效索引是包含所有三个字段的复合索引,例如:(object_id, user_id, location_id)。由于没有这样的索引,MySQL 会尽力从现有索引中获取大部分信息。

    【讨论】:

    • 对性能不利吗?我是否与个人指数复合?
    • @toleo,在像这样的简单查询中,mysql 可以猜测它可以合并索引并使用它们,但更常见的是它不会,最好对所需列有一个好的索引。性能取决于许多因素。索引允许 RDBMS 遍历比整个表更小的已排序数据子集,这通常更快,但索引会消耗内存,这可能会以其他方式影响性能。
    • @newtover 所以在我的情况下在这里:Columns = [1, 2, 3, 4, 5] 所有这些都单独和一起使用根据用户的喜好,我制作了以下键,这些键给了我 index_merge Keys = [1, 2, 3, 4, 5],我是否保持这样还是选择Keys = [1, 2, 3, 4, 5, 12, 13, 14, 15, 23, 24, 25, 34, 35, 45,~~] 等等?我发现 index_merge 更好,但你有什么建议?
    猜你喜欢
    • 2021-12-04
    • 2021-12-21
    • 2020-12-02
    • 1970-01-01
    • 2020-10-03
    • 1970-01-01
    • 1970-01-01
    • 2021-07-02
    • 1970-01-01
    相关资源
    最近更新 更多