База данных: медленное восстановление/обновление/вставка проблемы с записью более 5 мил в каждой таблице

Question

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

В настоящее время у меня есть база данных с более чем 5-мильными записями в одной таблице, что приводит к медленному извлечению данных. В настоящее время я ищу способы структурирования базы данных, чтобы избежать такой базы данных. (Database Engine MyISAM)

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

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

есть ли способ сохранения данных (около 5mil записей в каждом) в базе данных 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 

Answer 1

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

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

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

Update:

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, но этот пункт также очень важен, используя индексы также могут его улучшить.

Answer 2

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

Answer 3

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

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

Edit:

Вы могли бы попробовать, если при добавлении INDEX (ИДП, author_id) или INDEX (author_id, ИДП) на столе ibf_posts помогает.