mysql - 我们如何在使用连接时极大地优化我们的 MySQL 数据库(或替换它)？

Question

这是我第一次遇到极高容量的情况。这是一个基于 MySQL 的广告服务器。但是，所使用的查询包含大量 JOIN，并且通常慢。 (这是 Rails ActiveRecord，顺便说一句)

sel = Ads.find(:all, :select => '*', :joins => "JOIN campaigns ON ads.campaign_id = campaigns.id JOIN users ON campaigns.user_id = users.id LEFT JOIN countries ON countries.campaign_id = campaigns.id LEFT JOIN keywords ON keywords.campaign_id = campaigns.id", :conditions => [flashstr + "keywords.word = ? AND ads.format = ? AND campaigns.cenabled = 1 AND (countries.country IS NULL OR countries.country = ?) AND ads.enabled = 1 AND campaigns.dailyenabled = 1 AND users.uenabled = 1", kw, format, viewer['country'][0]], :order => order, :limit => limit)

我的问题:

1. 是否有像 MySQL 这样支持 JOIN 但速度更快的替代数据库？ (我知道有 Postgre，仍在评估中。)

2. 否则，启动 MySQL 实例、将本地数据库加载到内存中并每 5 分钟重新加载一次会有帮助吗？

3. 否则，有什么方法可以将整个操作切换到 Redis 或 Cassandra，并以某种方式更改 JOIN 行为以匹配 NoSQL 的(不可连接)性质？

谢谢!

---

编辑:这里有更多细节:

带有扁平化选择的完整执行的 SQL(上面被截断):

SELECT campaigns.id, campaigns.guid, campaigns.user_id, campaigns.dailylimit, campaigns.impressions, campaigns.cenabled, campaigns.dayspent, campaigns.dailyenabled, campaigns.fr, ads.id, ads.guid, ads.user_id, ads.campaign_id, ads.format, ads.enabled, ads.datafile, ads.data1, ads.data2, ads.originalfilename, ads.aid, ads.impressions, countries.id, countries.guid, countries.campaign_id, countries.country, keywords.id, keywords.campaign_id, keywords.word, keywords.bid FROM ads JOIN campaigns ON ads.campaign_id = campaigns.id JOIN users ON campaigns.user_id = users.id LEFT JOIN countries ON countries.campaign_id = campaigns.id LEFT JOIN keywords ON keywords.campaign_id = campaigns.id WHERE (keywords.word = 'design' AND ads.format = 10 AND campaigns.cenabled = 1 AND (countries.country IS NULL OR countries.country = 82) AND ads.enabled = 1 AND campaigns.dailyenabled = 1 AND users.uenabled = 1 AND ads.datafile != '') ORDER BY keywords.bid DESC LIMIT 1,1

解释/执行计划:

+----+-------------+-----------+--------+------------------+-------------+---------+------------------------------------+------+----------------------------------------------+
| id | select_type | table     | type   | possible_keys    | key         | key_len | ref                                | rows | Extra                                        |
+----+-------------+-----------+--------+------------------+-------------+---------+------------------------------------+------+----------------------------------------------+
|  1 | SIMPLE      | keywords  | ref    | campaign_id,word | word        | 257     | const                              |    9 | Using where; Using temporary; Using filesort | 
|  1 | SIMPLE      | ads       | ref    | campaign_id      | campaign_id | 4       | e_development.keywords.campaign_id |    8 | Using where                                  | 
|  1 | SIMPLE      | campaigns | eq_ref | PRIMARY          | PRIMARY     | 4       | e_development.keywords.campaign_id |    1 | Using where                                  | 
|  1 | SIMPLE      | users     | eq_ref | PRIMARY          | PRIMARY     | 4       | e_development.campaigns.user_id    |    1 | Using where                                  | 
|  1 | SIMPLE      | countries | ALL    | campaign_id      | NULL        | NULL    | NULL                               |    4 | Using where                                  | 
+----+-------------+-----------+--------+------------------+-------------+---------+------------------------------------+------+----------------------------------------------+

(这是在开发数据库上，它的行数几乎没有生产版本那么多。)

定义的索引:

ads -> id (primary, autoinc) + aid (unique) + campaign_id (index) + user_id (index)
campaigns -> id (primary, autoinc) + user_id (index)
countries -> id (primary, autoinc) + campaign_id (index) + country (index) + user_id (index)
keywords -> id (primary, autoinc) + campaign_id (index) + word (index) + user_id (index)
user -> id (primary, autoinc)

Answer 1

数据库理论和名义实践的存在为大多数情况提供了一个框架。并非每个数据库使用模式都符合第三范式。因此出现了NoSQL。这些数据库在大多数情况下效果不佳，但在特定情况下效果很好。它们工作良好的原因之一是因为它们不像普通的 RDBMS 那样工作。 Cassandra 确实有一些“加入”的功能，但我不记得具体细节了。如果您想快速了解，我推荐 Digg 开发人员博客。有一个很好的简单描述。

问题是我敢打赌，连接 4 个表比 mySQL 慢。唯一可以确定的方法是学习一个新的 DBMS，安装它，调整安装以及调整 MySQL 和设置所有数据以及......你会发现 MySQL 做得非常好.

尝试使用不同的引擎以完全相同的方式解决完全相同的问题不会成功...您必须像 NoSQL 开发人员一样思考，而不是使用 NoSQL 的 RDBMS 开发人员。

但是你可以按照 Frustrated 的建议来思考这个问题。

为什么我们有第三范式？主要是易于更新。我更新一行而不是几十行。它还有助于限制数据，如果我仔细控制国家表中国家的添加，我将永远不会在事件表中得到一个坏的。之后，3NF 并没有让查询变得更快，这就是我们发明报告数据库、OLAP、多维数据集、星型模式的原因。

关键是报告与编辑/捕获的结构不同。

正如 Frustrated 所说，确定基础数据的变化速度。如果您真的每 5 分钟添加一次国家/地区，我会感到震惊。事件？可能偶尔？广告？一天几次。构建一个完全扁平化的表并对其进行索引需要多长时间？这会产生多少行？如果该周期时间比您的更新频率短得多...构建并查看。测试查询速度。与使用全新的数据库相比，这是一个更便宜的实验。