Предложение по структуре базы данных для реляционных данных

Question

Я уже давно борюсь с этой проблемой, и автоматические письма с предупреждениями 'Slow Query' все еще появляются. В основном, у меня есть блоги с соответствующей таблицей, а также таблица, которая отслеживает много раз каждый блог был просмотрен. Эта последняя таблица содержит огромное количество записей, так как на этой странице достаточно высокий трафик, и каждый журнал регистрируется как отдельная строка. Я пытался с индексами на полях, которые включены в предложение 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 ;

Answer 1

Скорее всего, вам понадобится один индекс для обоих столбцов blog_id и creation_at

Не два индекса с одним столбцом в каждом ...

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

С CREATE TABLE вы можете иметь составные индексы / ключи:

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

и попробуйте поменять порядок, если это не работает

Answer 2

Моя идея такая же, как у Piero, но с некоторыми отличиями.

Вы можете добавить один столбец в таблицу блога с именем «hit» и всегда увеличивать значение этого поля при обращении к нему, а также вставлять новую запись вblog_view таблица, как вы делаете сейчас.

, выполнив, вам не нужно запускать запрос для подсчета показов, а также вы можете просмотреть информацию о попаданиях, когда это необходимо.

Answer 3

Я бы не регистрировал каждый удар как уникальную строку ....

Если вам нужно только посчитать, сколько раз просматривается блог, почему бы вам не создать по одной строке для каждого блога и добавить поле view_count в вашу таблицу. Тогда обновляется только это поле ....

Если вам нужно отслеживать пользователей / ips и вы хотите знать, сколько раз каждый пользователь нажимал на блоги, то создайте дополнительную таблицу в структуре, похожей на эту:

id (pk)

blog_id

user_id / ip_address

дата

hit_counts

С такой структурой вы можете получить общее представление о том, сколько раз был просмотрен блог, а также о том, сколько пользователей и сколько раз каждый пользователь нажал ...

В противном случае, если вы действительно хотите создавать строки для каждого попадания и если индексы недостаточно ускоряют процесс, вы можете рассмотреть вопрос о более мощном сервере или другой системе управления базами данных ...

Надеюсь, это поможет!