关于关系数据的数据库结构的建议

时间:2010-04-19 13:50:37

标签: mysql ruby-on-rails performance

我一直在努力解决这个问题已经有一段时间了,而且“慢速查询”警告的自动邮件仍然存在。基本上,我有一个带有相应表格的博客以及一个跟踪如何跟踪的表格很多时候每个博客都被查看过。最后一个表有大量的记录,因为此页面的流量相对较高,它将每个匹配记录为单个行。我已尝试使用WHERE子句中包含的字段的索引,但它似乎没有帮助。我还试图通过删除旧的(> 1.weeks)记录每周清理一次表。所以,我问你们,你们怎么解决这个问题?

我知道的查询导致缓慢是由Rails生成的,如下所示:

SELECT count(*) AS count_all
FROM blog_views
WHERE (created_at >= '2010-01-01 00:00:01' AND blog_id = 1);

表格具有以下结构:

CREATE TABLE IF NOT EXISTS 'blogs' (
  'id' int(11) NOT NULL auto_increment,
  'name' varchar(255) default NULL,
  'perma_name' varchar(255) default NULL,
  'author_id' int(11) default NULL,
  'created_at' datetime default NULL,
  'updated_at' datetime default NULL,`
  'blog_picture_id' int(11) default NULL,
  'blog_picture2_id' int(11) default NULL,
  'page_id' int(11) default NULL,
  'blog_picture3_id' int(11) default NULL,
  'active' tinyint(1) default '1',
  PRIMARY KEY  ('id'),
  KEY 'index_blogs_on_author_id' ('author_id')
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS 'blog_views' (
  'id' int(11) NOT NULL auto_increment,
  'blog_id' int(11) default NULL,
  'ip' varchar(255) default NULL,
  'created_at' datetime default NULL,
  'updated_at' datetime default NULL,
  PRIMARY KEY  ('id'),
  KEY 'index_blog_views_on_blog_id' ('blog_id'),
  KEY 'created_at' ('created_at')
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

3 个答案:

答案 0 :(得分:2)

最有可能的是,两个列上的一个索引blog_id和created_at

不是两个索引,每个索引一列......

...
KEY 'whizzy' ('blog_id', 'created_at'),
...

CREATE TABLE开始,您可以拥有复合索引/键:

...
{INDEX|KEY} [index_name] [index_type] (index_col_name,...)
...

并尝试撤消订单,如果这不起作用

答案 1 :(得分:1)

我不会将每个匹配记录为唯一的行....

如果您想要做的只是计算浏览博客的次数,为什么不为每个博客创建一行,并将view_count字段添加到您的表中。 然后只有这个字段正在更新....

如果您需要跟踪用户/ ips,并且想知道每个用户点击博客的次数,那么在类似于此的结构中创建一个额外的表:

id(pk)

blog_id

user_id / ip_address

日期

hit_counts

通过这样的结构,您可以概览博客的浏览次数,也可以了解每个用户点击的用户数量和次数......

或者,如果你真的想为每次点击创建行,并且索引没有足够的流量,你可能会考虑更强大的服务器或不同的数据库管理系统......

希望这有帮助!

答案 2 :(得分:1)

我的想法与piero相同,但有些不同。

您可以在名为“hits”的博客表中添加一列,并在发生匹配时始终增加此字段的值,并且同样在blog_view表中插入新记录,就像现在一样。

通过执行操作,您无需运行查询来计算命中数,也可以在需要时查看命中详细信息。