Проблема медленного извлечения / обновления / вставки базы данных с более чем 5 миллионами записей в каждой таблице - PullRequest
Новая
       31

Проблема медленного извлечения / обновления / вставки базы данных с более чем 5 миллионами записей в каждой таблице

1 голос
/ 25 декабря 2009

Как структурировать базу данных, чтобы избежать замедлений? (Двигатель: MyISAM)

В настоящее время у меня есть база данных с более чем 5 миллионами записей в одной таблице, что вызывает медленный поиск данных. В настоящее время я ищу способы структурировать базу данных, чтобы избежать такого рода базы данных. (СУБД MyISAM)

Таблицы, которые вызывают проблемы, - это сообщения и комментарии, содержащие более 5 миллионов записей в каждой.

У меня была идея использовать текстовый файл в качестве хранилища при сохранении записей по дате, чтобы каждый файл содержал достаточно данных, которые не замедляли процесс извлечения и сохранения, но с базами данных я не знаю, что делать: (

Есть ли способ сохранить данные (около 5 миллионов записей в каждой) в базе данных MySQL, чтобы не вызывать медленный поиск, вставку или обновление данных?

Структура "сообщений" 

    CREATE TABLE IF NOT EXISTS `ibf_posts` (
  `pid` int(10) NOT NULL auto_increment,
  `append_edit` tinyint(1) default '0',
  `edit_time` int(10) default NULL,
  `author_id` mediumint(8) NOT NULL default '0',
  `author_name` varchar(32) default NULL,
  `use_sig` tinyint(1) NOT NULL default '0',
  `use_emo` tinyint(1) NOT NULL default '0',
  `ip_address` varchar(16) default NULL,
  `post_date` int(10) default NULL,
  `icon_id` smallint(3) default NULL,
  `post` text,
  `queued` tinyint(1) NOT NULL default '0',
  `topic_id` int(10) NOT NULL default '0',
  `post_title` varchar(255) default NULL,
  `new_topic` tinyint(1) default '0',
  `edit_name` varchar(255) default NULL,
  `post_key` varchar(32) default NULL,
  `post_parent` int(10) NOT NULL default '0',
  `post_htmlstate` smallint(1) NOT NULL default '0',
  `post_edit_reason` varchar(255) default NULL,
  PRIMARY KEY  (`pid`),
  KEY `topic_id` (`topic_id`,`queued`,`pid`,`post_date`),
  KEY `author_id` (`author_id`,`topic_id`),
  KEY `post_date` (`post_date`),
  KEY `ip_address` (`ip_address`),
  KEY `post_key` (`post_key`),
  FULLTEXT KEY `post` (`post`),
  FULLTEXT KEY `post_2` (`post`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8;

Запрос: 

SELECT p.*, pp.*,.id,m.name,m.mgroup,m.email,m.joined,m.posts, m.last_visit, m.last_activity,m.login_anonymous,m.title,m.hide_email, m.warn_level, m.warn_lastwarn, m.points, m.topics_started, m.skin,
                    me.msnname,me.aim_name,me.icq_number,me.signature, me.website,me.yahoo,me.location, me.avatar_location, me.avatar_type, me.avatar_size, m.members_display_name, m.custom_post_css, m.custom_right_img
                    m.custom_post_color
                        FROM posts p
                            LEFT JOIN members m ON (m.id=p.author_id)
                            LEFT JOIN profile_portal pp ON (m.id=pp.pp_member_id)
                            LEFT JOIN member_extra me ON (me.id=m.id)
                        WHERE p.pid IN(--post ids here) 
                        ORDER BY --ordering here

Ответы [ 3 ]

2 голосов
/ 25 декабря 2009

5M не так уж много.

Возможно, вы неправильно проиндексировали таблицу.

Пожалуйста, оставьте свой запрос, и мы, вероятно, расскажем, как его улучшить.

Обновление: 

SELECT  p.*, pp.*,.id,m.name,m.mgroup,m.email,m.joined,m.posts, m.last_visit, m.last_activity,m.login_anonymous,m.title,m.hide_email, m.warn_level, m.warn_lastwarn, m.points, m.topics_started, m.skin,
        me.msnname,me.aim_name,me.icq_number,me.signature, me.website,me.yahoo,me.location, me.avatar_location, me.avatar_type, me.avatar_size, m.members_display_name, m.custom_post_css, m.custom_right_img
        m.custom_post_color
FROM    posts p
LEFT JOIN
        members m
ON      m.id = p.author_id 
LEFT JOIN
        profile_portal pp
ON      pp.pp_member_id = m.id
LEFT JOIN
        member_extra me
ON      me.id = m.id
WHERE   p.pid IN (--post ids here) 
ORDER BY
        --ordering here

Убедитесь, что:

  • members.id является PRIMARY KEY
  • member_extra.id является PRIMARY KEY
  • У вас есть индекс на profile_portal.pp_member_id

Также вы пропустили предложение ORDER BY, но это предложение также важно, использование индексов также может улучшить его.

0 голосов
/ 25 декабря 2009

5M строк в одной таблице - это не так много, сколько времени занимают ваши запросы? Я подозреваю, что у вас могут быть некоторые проблемы с индексацией. EXPLAIN может помочь узнать, что на самом деле делают ваши запросы.

Если вы правильно проиндексировали таблицы и вменяемые запросы, вы можете посмотреть разбиение. .

Edit:

Вы можете попробовать, если поможет добавление INDEX (pid, author_id) или INDEX (author_id, pid) к таблице ibf_posts.

0 голосов
/ 25 декабря 2009

EXPLAIN PLAN расскажет вам, как это делает механизм запросов. Если вы видите «сканирование таблицы», вы знаете, что вам нужны индексы.

...