0

你能告诉我为什么这样的查询会花这么长时间（字面意思是 20-30 分钟）吗？我似乎设置了适当的索引，不是吗？

UPDATE  `temp_val_import_435` t1,
`attr_upc` t2 SET t1.`attr_id` = t2.`id` WHERE t1.`value` LIKE t2.`upc`


CREATE TABLE `attr_upc` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `upc` varchar(255) NOT NULL,
 `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (`id`),
 UNIQUE KEY `upc` (`upc`),
 KEY `last_update` (`last_update`)
) ENGINE=InnoDB AUTO_INCREMENT=102739 DEFAULT CHARSET=utf8


CREATE TABLE `temp_val_import_435` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `attr_id` int(11) DEFAULT NULL,
 `translation_id` int(11) DEFAULT NULL,
 `source_value` varchar(255) NOT NULL,
 `value` varchar(255) DEFAULT NULL,
 `count` int(11) NOT NULL,
 PRIMARY KEY (`id`),
 KEY `core_value_id` (`core_value_id`),
 KEY `translation_id` (`translation_id`),
 KEY `source_value` (`source_value`),
 KEY `value` (`value`),
 KEY `count` (`count`)
) ENGINE=InnoDB AUTO_INCREMENT=32768 DEFAULT CHARSET=utf8

Ed Cottrell 的解决方案对我有用。使用=而不是LIKE在 1000 行上加速了一个较小的测试查询。

我测量了 2 种方式：1 在 phpMyAdmin 中，另一种查看 DOM 加载的时间（这当然涉及其他进程）。

DOM 负载从 44 秒缩短到 1 秒，增加了 98%。

但查询执行时间的差异更为显着，从 43.4 秒变为 0.0052 秒，减少了 99.988%。非常好。我将报告来自大量数据集的结果。

4

2 回答 2

2

使用=而不是LIKE. 应该比--仅用于匹配模式=要快得多，例如，它匹配文本中任何位置带有“某物”的任何内容。LIKELIKE'%something%'

如果您有此查询：

SELECT * FROM myTable where myColumn LIKE 'blah'

MySQL 可以通过假装您键入来优化这一点myColumn = 'blah'，因为它认为模式是固定的并且没有通配符。但是，如果您的upc列中有这些数据怎么办：

blah
foo
bar
%foo%
%bar
etc.

MySQL 无法提前优化您的查询，因为它尝试匹配的文本可能是一个模式，例如%foo%. 因此，它必须针对 的每个单个值执行全文搜索以LIKE匹配. 使用您定义的简单索引和索引，这是不必要的，并且查询应该会大大加快。temp_val_import_435.valueattr_upc.upc=

于 2013-11-09T00:50:39.293 回答
0

从本质上讲，您正在加入一个 LIKE，这将是有问题的（如果完全使用索引，则需要 EXPLAIN 才能看到 MySQL）。尝试这个：

UPDATE  `temp_val_import_435` t1
INNER JOIN `attr_upc` t2
  ON t1.`value` LIKE t2.`upc`
SET t1.`attr_id` = t2.`id` WHERE t1.`value` LIKE t2.`upc`
于 2013-11-09T00:50:51.173 回答