Banco de dados Recuperação Slow/Atualização/Inserção do Problema com mais de 5mil Records em cada tabela

Question

Como estruturar o banco de dados para evitar desacelerações? (Motor: Myisam)

Atualmente, tenho banco de dados com mais de 5milion registros em uma tabela que causa a recuperação de dados lentos. Atualmente, estou procurando maneiras de estruturar o banco de dados para evitar esse tipo de banco de dados. (Engine de banco de dados Myisam)

Tabelas que causam problemas são postagens e comentários com mais de 5mil registros em cada um.

Eu tive uma idéia ao usar o arquivo de texto como armazenamento ao salvar registros por data, para que cada arquivo contivesse dados suficientes que não estavam diminuindo a recuperação e a economia de processos, mas com bancos de dados, não sei o que fazer :(

Existe alguma maneira de salvar dados (aproximadamente 5mil registros em cada) no banco de dados MySQL para não causar recuperação, inserção ou atualização de dados lentos?

Estrutura de "postagens"

    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;

Consulta:

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 não é muito.

Provavelmente você indexou a tabela errada.

Por favor, poste sua consulta e provavelmente diremos como melhorá -la.

Atualizar:

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

Certifique -se de que:

• members.id é um PRIMARY KEY
• member_extra.id é um PRIMARY KEY
• Você tem um índice em profile_portal.pp_member_id

Também você omitiu o ORDER BY Cláusula Mas essa cláusula também é importante, o uso de índices também pode melhorá -la.

Answer 2

O Plano de Explicação dirá como o mecanismo de consulta está fazendo isso. Se você vir "Tabela Scan", sabe que precisa de índices.

Answer 3

5m linhas em uma tabela não é tanto, quanto tempo suas consultas estão demorando? Eu suspeito que você possa ter alguns problemas com a indexação. EXPLIQUE A declaração pode ajudar a descobrir o que você está realmente fazendo.

Se você tiver tabelas indexadas adequadamente e consultas sãs, você pode olhar para partição..

Editar:

Você pode tentar se adicionar Índice (PID, Author_ID) ou Index (Author_Id, PID) na Tabela IBF_POSTS Ajuda.