Mysql 查询时间呈指数级增长？

在过去的几天里，我一直在努力规范化我们的600GB数据库。 我将所有冗余数据分解成4个单独的表和一个主条目表

到目前为止一切正常，但最后一步是将新表与旧数据记录连接起来，并将新的规范化数据记录插入数据库。但这不是问题所在。如果我在前100个id上运行此查询，则需要10秒，但如果在前300行上运行此查询，则需要几分钟。我能做些什么来解决这个问题

SELECT * FROM oldDB.`unNormalized` 
INNER JOIN `new_normalized_db`.`keyword` k ON `unNormalized_tabel`.`keyword` = k.`keyword`
INNER JOIN `new_normalized_db`.`project` p ON `unNormalized_tabel`.`awrProject` = p.`project`
INNER JOIN `new_normalized_db`.`searchEngine` s ON `unNormalized_tabel`.`searchEngine` = s.`searchEngine`
INNER JOIN `new_normalized_db`.`urlHash` u ON MD5(`unNormalized_tabel`.`url`) = u.`hash`
WHERE oldDB.`unNormalized_tabel`.`id` < 100
GROUP BY k.`id`, p.`id`, s.`id`,u.`id`

---

您可以通过添加索引来加快查询速度

如果在关键字上有一个索引，并且在非标准化的表格上也有一个索引，那么k的第一次连接会更快。关键字对于带有awrProject和p.project的项目p和s.searchEngine以及非标准化的表格searchEngine也是如此

---

但最后一次连接无论如何都会很慢，因为必须在查询时计算哈希，这在很多数据上非常慢。您可以做的是先对url进行散列，然后再插入到非规范化的选项卡中，然后在散列字段中添加索引。

我想在最后一个联接条件中无法摆脱MD5函数调用？两条一般规则：1联接中使用的列应为全文索引，不一定需要，非集群可以获得最佳性能，2个函数通常会否定在连接上使用索引的能力，因此MD5函数可能会导致严重的问题。您可以使用EXPLAIN检查查询的工作方式，我可以删除MD5哈希并只匹配纯URL，但在小测试用例10行中，MD5匹配实际上更快：/

 id  select_type  table              type    possible_keys                                                    key           key_len  ref                                 rows  Extra                                         
------  -----------  -----------------  ------  ---------------------------------------------------------------  ------------  -------  --------------------------------  ------  ----------------------------------------------
     1  SIMPLE       p                  index   (NULL)                                                           projectName   42       (NULL)                               427  Using index; Using temporary; Using filesort  
     1  SIMPLE       unormalized_tabel  range   PRIMARY,keyword_url_insDate,keyword,searchEngine,url,awrProject  PRIMARY       4        (NULL)                               358  Using where; Using join buffer                
     1  SIMPLE       u                  ref     url                                                              url           767      oldDB.unormalized_tabel.url       1                                                
     1  SIMPLE       k                  index   (NULL)                                                           keyword       42       (NULL)                            107340  Using where; Using index; Using join buffer   
     1  SIMPLE       s                  index   (NULL)                                                           searchEngine  42       (NULL)                              1155  Using where; Using index; Using join buffer