在我们的生产环境中,我注意到一个查询的零星性能缓慢。
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'
答案 0 :(得分:0)
(不是一个明确的答案,各种各样的ramblings,以及一些问题......)
该指数接近最佳; EXPLAIN
表示它正在使用最佳索引。假设结果集没有返回成千上万的行,我必须走出困境并且猜测这个查询不是恶棍。
如果正在运行另一个查询(当这个查询太慢时),并且该查询在这个表上大量打击(可能是写入),那么它可能会减慢此查询的速度。 FK正在增加开销。
或者,另一个查询充斥着buffer_pool,将事情从缓存中剔除,导致I / O突然激增。
或者,你有一百个连接都在主动做某事,但没有快速完成。 (这是争夺资源的情况,每个人都获得了公平的分享;没有人能够快速完成。)
使用long_query_time=1
打开slowlog并通过pt-query-digest
或mydumpslow -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 。
这是最常执行的查询之一,因此每当服务器上出现繁重的冲突时,它就会开始等待。它不会出现在慢速日志中,但新的遗物会将其捕获为慢速查询。