生产数据库上快速的查询在本地导入副本上非常慢

Question

如果我将生产数据库导出到 .sql 文件，然后将其导入本地计算机，则在生产数据库上运行非常快（90 毫秒）的完全相同的查询在本地运行速度非常慢（100 秒或更长时间）。

生产mysql版本：5.7.18 本地mysql版本：5.7.21

我检查了一下，看起来所有索引都在那里，并且在两个数据库中都相同。唯一的区别是索引上的基数值不同。那会有什么不同吗？

下面是一个很慢的查询示例：

SELECT DISTINCT v0.`id` 
FROM `visibility__slugs` AS v0 
INNER JOIN `visibility__business_type_slug` AS v5 ON v5.`slug_id` = v0.`id` 
INNER JOIN `visibility__business_types` AS v1 ON (v5.`business_type_id` = v1.`id`) AND (v1.`type_name` != 'Other') 
INNER JOIN `visibility__business_type_page` AS v6 ON v6.`business_type_id` = v1.`id` 
INNER JOIN `visibility__pages` AS v2 ON v6.`page_id` = v2.`id` 
INNER JOIN `visibility__page_postal_code` AS v7 ON v7.`page_id` = v2.`id` 
INNER JOIN `visibility__postal_codes` AS v3 ON v7.`postal_code` = v3.`postal_code` 
WHERE (v2.`is_live`) 

这里是EXPLAIN

1 SIMPLE  v0  NULL  index PRIMARY,visibility__slugs_slug_unique visibility__slugs_slug_unique 767 NULL  1 100.00  Using index; Using temporary
1 SIMPLE  v3  NULL  index visibility__postal_codes_postal_code_unique,visibility__postal_codes_postal_code_index  visibility__postal_codes_postal_code_index  767 NULL  1 100.00  Using index; Distinct; Using join buffer (Block Nested Loop)
1 SIMPLE  v5  NULL  ref visibility__business_type_slug_slug_id_business_type_id_unique,visibility__business_type_slug_slug_id_index,visibility__business_type_slug_business_type_id_index visibility__business_type_slug_slug_id_index  4 zipbooks_development.v0.id  1 100.00  Using index; Distinct
1 SIMPLE  v1  NULL  eq_ref  PRIMARY PRIMARY 4 zipbooks_development.v5.business_type_id  1 90.00 Using where; Distinct
1 SIMPLE  v6  NULL  ref visibility__business_type_page_page_id_business_type_id_unique,visibility__business_type_page_page_id_index,visibility__business_type_page_business_type_id_index visibility__business_type_page_business_type_id_index 4 zipbooks_development.v5.business_type_id  15  100.00  Using index; Distinct
1 SIMPLE  v2  NULL  eq_ref  PRIMARY PRIMARY 4 zipbooks_development.v6.page_id 1 90.00 Using where; Distinct
1 SIMPLE  v7  NULL  eq_ref  visibility__page_postal_code_page_id_postal_code_unique,visibility__page_postal_code_page_id_index,visibility__page_postal_code_postal_code_index visibility__page_postal_code_page_id_postal_code_unique 771 zipbooks_development.v6.page_id,zipbooks_development.v3.postal_code 1 100.00  Using index; Distinct

这是慢查询日志：

Time                 Id Command    Argument# Time: 2018-02-14T18:12:40.968206Z
# User@Host: root[root] @ localhost [127.0.0.1]  Id:     2
# Query_time: 191.781505  Lock_time: 0.000142 Rows_sent: 0  Rows_examined: 183768270
SET timestamp=1518631960;
SELECT DISTINCT v0.`id` 
FROM `visibility__slugs` AS v0 
INNER JOIN `visibility__business_type_slug` AS v5 ON v5.`slug_id` = v0.`id` 
INNER JOIN `visibility__business_types` AS v1 ON (v5.`business_type_id` = v1.`id`) AND (v1.`type_name` != 'Other') 
INNER JOIN `visibility__business_type_page` AS v6 ON v6.`business_type_id` = v1.`id` 
INNER JOIN `visibility__pages` AS v2 ON v6.`page_id` = v2.`id` 
INNER JOIN `visibility__page_postal_code` AS v7 ON v7.`page_id` = v2.`id` 
INNER JOIN `visibility__postal_codes` AS v3 ON v7.`postal_code` = v3.`postal_code` 
WHERE (v2.`is_live`);

有趣的是，有时它会起作用。有时我会导入备份，并且查询与生产环境一样快。我没有看到它何时工作和导入后查询非常慢之间的模式，但值得注意的是。会不会和我们使用--single-transaction --quick 转储生产有关？

谁能想到一些我可以尝试的事情？配置值？这里可能有什么问题？

Answer 1

我的索引已损坏。我找到了有问题的桌子并跑了

ALTER TABLE visibility__postal_codes ENGINE = InnoDB;

重建索引，现在它已修复。