解释插入在不同执行中显示不同的可能键

Question

我正在尝试使用 EXPLAIN EXTENDED 对缓慢的 INSERT 查询进行故障排除。我认为问题在于钥匙没有正确使用。对同一查询多次执行 EXPLAIN EXTENDED 将导致不同的结果。在后台没有运行 cron，这是在临时服务器上，因此除了我之外现在没有流量，并且没有发生表架构更改。

查询：

INSERT INTO `catalog_product_entity_varchar` (
  `attribute_id`,
  `store_id`,
  `value`,
  `row_id`
)
VALUES
  (
    '442',
    '0',
    'https://www.example.com/item/',
    '46242'
  )
  ON DUPLICATE KEY
  UPDATE
    `attribute_id` = VALUES(`attribute_id`),
    `store_id` = VALUES(`store_id`),
    `value` = VALUES(`value`),
    `row_id` = VALUES(`row_id`);

解释查询：

explain extended
INSERT INTO `catalog_product_entity_varchar` (
  `attribute_id`,
  `store_id`,
  `value`,
  `row_id`
)
VALUES
  (
    '442',
    '0',
    'https://www.sexample.com/item/',
    '46242'
  )
  ON DUPLICATE KEY
  UPDATE
    `attribute_id` = VALUES(`attribute_id`),
    `store_id` = VALUES(`store_id`),
    `value` = VALUES(`value`),
    `row_id` = VALUES(`row_id`);

解释回应 1：

    id  select_type  table                           partitions  type    possible_keys                                                                        key     key_len  ref       rows  filtered  Extra   
------  -----------  ------------------------------  ----------  ------  -----------------------------------------------------------------------------------  ------  -------  ------  ------  --------  --------
     1  INSERT       catalog_product_entity_varchar  (NULL)      ALL     CATALOG_PRODUCT_ENTITY_VARCHAR_ATTRIBUTE_ID,CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID  (NULL)  (NULL)   (NULL)  (NULL)    (NULL)  (NULL)  

解释回应 2：

    id  select_type  table                           partitions  type    possible_keys                                                                        key     key_len  ref       rows  filtered  Extra   
------  -----------  ------------------------------  ----------  ------  -----------------------------------------------------------------------------------  ------  -------  ------  ------  --------  --------
     1  INSERT       catalog_product_entity_varchar  (NULL)      ALL     CATALOG_PRODUCT_ENTITY_VARCHAR_ROW_ID_ATTRIBUTE_ID_STORE_ID,CATALOG_PRODUCT_ENTITY_VARCHAR_ATTRIBUTE_ID,CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID  (NULL)  (NULL)   (NULL)  (NULL)    (NULL)  (NULL)  

解释回应 3：

    id  select_type  table                           partitions  type    possible_keys                                                                        key     key_len  ref       rows  filtered  Extra   
------  -----------  ------------------------------  ----------  ------  -----------------------------------------------------------------------------------  ------  -------  ------  ------  --------  --------
     1  INSERT       catalog_product_entity_varchar  (NULL)      ALL     CATALOG_PRODUCT_ENTITY_VARCHAR_ATTRIBUTE_ID  (NULL)  (NULL)   (NULL)  (NULL)    (NULL)  (NULL)  

有几次，possible_keys 返回空白。

我怀疑当优化器选择响应 2 中的键时，它是一个快速插入。什么会导致 EXPLAIN 响应发生这样的变化？

版本信息：

aurora_version           2.11.1                        
innodb_version           5.7.12                        
protocol_version         10                            
slave_type_conversions                                 
tls_version              TLSv1,TLSv1.1,TLSv1.2         
version                  5.7.12-log                    
version_comment          MySQL Community Server (GPL)  
version_compile_machine  x86_64                        
version_compile_os       Linux

表创建表：

CREATE TABLE `catalog_product_entity_varchar` (
  `value_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Value ID',
  `attribute_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute ID',
  `store_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Store ID',
  `value` varchar(255) DEFAULT NULL COMMENT 'Value',
  `row_id` int(10) unsigned NOT NULL COMMENT 'Version Id',
  PRIMARY KEY (`value_id`),
  UNIQUE KEY `CATALOG_PRODUCT_ENTITY_VARCHAR_ROW_ID_ATTRIBUTE_ID_STORE_ID` (`row_id`,`attribute_id`,`store_id`),
  KEY `CATALOG_PRODUCT_ENTITY_VARCHAR_ATTRIBUTE_ID` (`attribute_id`),
  KEY `CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID` (`store_id`),
  CONSTRAINT `CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `store` (`store_id`) ON DELETE CASCADE,
  CONSTRAINT `CAT_PRD_ENTT_VCHR_ATTR_ID_EAV_ATTR_ATTR_ID` FOREIGN KEY (`attribute_id`) REFERENCES `eav_attribute` (`attribute_id`) ON DELETE CASCADE,
  CONSTRAINT `CAT_PRD_ENTT_VCHR_ROW_ID_CAT_PRD_ENTT_ROW_ID` FOREIGN KEY (`row_id`) REFERENCES `catalog_product_entity` (`row_id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=567985353 DEFAULT CHARSET=utf8 COMMENT='Catalog Product Varchar Attribute Backend Table'

行数 2,813,210 行。

最后，这种情况也发生在其他桌子上，而不仅仅是这张桌子。

这种情况在制作和舞台上都会发生，但似乎在舞台上更多地发生。

Answer 1

该表有 2 个唯一索引。 IODKU 必须检查为其提供值的任何一个。

PRIMARY KEY (`value_id`),                     -- no check needed
UNIQUE (`row_id`,`attribute_id`,`store_id`),  -- checked

2 例：

• 如果存在具有该三元组的行，则它将是

  UPDATEd

  。
• 如果不存在这样的行，数据将被“INSERTed”。

您的不同实验有不同的值吗？

我从未在 IODKU 上使用过

EXPLAIN

—— 需要做什么是如此明显，以至于

EXPLAIN

不会告诉我任何有用的东西。

我认为

CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID

的情况是一个错误；建议在 bugs.mysql.com 提交报告