Magento core_url_rewrite零星的表现

时间:2016-11-12 05:07:26

标签: mysql magento-1.9 database-performance

在我们的生产环境中,我注意到一个查询的零星性能缓慢。

SELECT `core_url_rewrite`.*
    FROM `core_url_rewrite`
    WHERE (request_path IN (:path?, :path?, :path?, :path?))
    AND (store_id IN(?, ?)) 

从生产服务器解释计划是:

    id: 1
    select_type: SIMPLE
    table: core_url_rewrite
    type: range
    possible_keys: UNQ_CORE_URL_REWRITE_REQUEST_PATH_STORE_ID,IDX_CORE_URL_REWRITE_STORE_ID
    key: UNQ_CORE_URL_REWRITE_REQUEST_PATH_STORE_ID
    key_len: 770
    ref: NULL
    rows: 4
    Extra: Using index condition

Mysql版本:5.6.34。表中没有行:473847。通常它在不到1ms的时间内执行,但根据新遗物的一些Tx是:8.03s,5.35s,3.04s,2.97s,最后30分钟内的1.92s。

创建表格是:

    CREATE TABLE `core_url_rewrite` (
      `url_rewrite_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Rewrite Id',
      `store_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Store Id',
      `id_path` varchar(255) DEFAULT NULL COMMENT 'Id Path',
      `request_path` varchar(255) DEFAULT NULL COMMENT 'Request Path',
      `target_path` varchar(255) DEFAULT NULL COMMENT 'Target Path',
      `is_system` smallint(5) unsigned DEFAULT '1' COMMENT 'Defines is Rewrite System',
      `options` varchar(255) DEFAULT NULL COMMENT 'Options',
      `description` varchar(255) DEFAULT NULL COMMENT 'Deascription',
      `category_id` int(10) unsigned DEFAULT NULL COMMENT 'Category Id',
      `product_id` int(10) unsigned DEFAULT NULL COMMENT 'Product Id',
      PRIMARY KEY (`url_rewrite_id`),
      UNIQUE KEY `UNQ_CORE_URL_REWRITE_REQUEST_PATH_STORE_ID` (`request_path`,`store_id`),
      UNIQUE KEY `UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID` (`id_path`,`is_system`,`store_id`),
      KEY `IDX_CORE_URL_REWRITE_TARGET_PATH_STORE_ID` (`target_path`,`store_id`),
      KEY `IDX_CORE_URL_REWRITE_ID_PATH` (`id_path`),
      KEY `IDX_CORE_URL_REWRITE_STORE_ID` (`store_id`),
      KEY `FK_CORE_URL_REWRITE_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID` (`category_id`),
      KEY `FK_CORE_URL_REWRITE_PRODUCT_ID_CATALOG_CATEGORY_ENTITY_ENTITY_ID` (`product_id`),
      CONSTRAINT `FK_CORE_URL_REWRITE_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID` FOREIGN KEY (`category_id`) REFERENCES `catalog_category_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE,
      CONSTRAINT `FK_CORE_URL_REWRITE_PRODUCT_ID_CATALOG_CATEGORY_ENTITY_ENTITY_ID` FOREIGN KEY (`product_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE,
      CONSTRAINT `FK_CORE_URL_REWRITE_STORE_ID_CORE_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE ON UPDATE CASCADE
    ) ENGINE=InnoDB AUTO_INCREMENT=95984103 DEFAULT CHARSET=utf8 COMMENT='Url Rewrites'

2 个答案:

答案 0 :(得分:0)

(不是一个明确的答案,各种各样的ramblings,以及一些问题......)

该指数接近最佳; EXPLAIN表示它正在使用最佳索引。假设结果集没有返回成千上万的行,我必须走出困境并且猜测这个查询不是恶棍。

如果正在运行另一个查询(当这个查询太慢时),并且该查询在这个表上大量打击(可能是写入),那么它可能会减慢此查询的速度。 FK正在增加开销。

或者,另一个查询充斥着buffer_pool,将事情从缓存中剔除,导致I / O突然激增。

或者,你有一百个连接都在主动做某事,但没有快速完成。 (这是争夺资源的情况,每个人都获得了公平的分享;没有人能够快速完成。)

使用long_query_time=1打开slowlog并通过pt-query-digestmydumpslow -s t进行汇总有助于查找竞争查询。

检查RAM大小和innodb_buffer_pool_size,看后者是前者的重要百分比。 (如果它很小,那么可以导致I / O场景。)

除此之外,KEY(product_id)对于以product_id开头的3列密钥而言是多余的。冗余密钥会在INSERT上浪费时间。

另一方面:你有一个AUTO_INCREMENT已达到95M,这是限制(4B)的140 / th。做数学 - 你什么时候用完?同时,表中只有0.47M行。这意味着使用REPLACE(可能有更好的替代品)或其他一些烧伤' IDS。请详细说明您的INSERTs

一个解决方案(对于上一段)可能是摆脱url_rewrite_id并将UNIQUE其中一个密钥提升为PK。 (表格中有3个有意义的唯一键很少见。)促销有优点,但有很大的缺点,因为UNIQUE包括VARCHAR(255)。所以,我不会推荐

提升查询所使用的密钥会加快查询。

答案 1 :(得分:0)

这个问题的原因终于被诊断出来了,它与mysql无关! 我们的ulimit(默认值)为1024.我们将其更改为65535.您可以使用以下方法检查: ulimit -n

这是最常执行的查询之一,因此每当服务器上出现繁重的冲突时,它就会开始等待。它不会出现在慢速日志中,但新的遗物会将其捕获为慢速查询。