Base de datos retriving lenta / actualizar / insertar problema con más de 5mil registros de cada tabla

Question

¿Cómo estructurar la base de datos para evitar ralentizaciones? (Motor: MyISAM)

En este momento tengo la base de datos con más de 5milion registros en una tabla de datos que causa recuperación lenta. Actualmente estoy buscando la forma de la estructura de base de datos para evitar este tipo de base de datos. (Base de datos MyISAM Motor)

Las tablas que causan problemas son los mensajes y comentarios que tengan más de 5mil registros en cada uno.

Yo tenía una idea cuando se utiliza un archivo de texto como almacenamiento al guardar registros por fecha, por lo que cada archivo contenía suficientes datos que no fue desacelerando la recuperación y el ahorro de los procesos, pero con las bases de datos que no sé qué hacer: (

¿Hay alguna manera de guardar los datos (aprox 5mil registros en cada uno) en la base de datos MySQL no causar recuperación lenta, insertar o actualizar datos?

"mensajes" Estructura

    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 no es mucho.

Es probable que indexa la mesa equivocada.

Por favor enviar su consulta y que, probablemente, le diremos cómo mejorarlo.

Actualización:

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

Asegúrese de que:

• members.id es un PRIMARY KEY
• member_extra.id es un PRIMARY KEY
• Usted tiene un índice en profile_portal.pp_member_id

También se omite la cláusula ORDER BY pero esta cláusula es importante también, el uso de índices puede mejorar también.

Answer 2

Explain Plan le dirá cómo el motor de consulta está haciendo. Si ve "exploración de tabla", usted sabe que necesita índices.

Answer 3

5M filas en una tabla que no es mucho, tiempo durante el que las consultas están tomando? Me sospecha que puede tener algunos problemas con la indexación. EXPLAIN puede ayudar a averiguar lo que las consultas en realidad están haciendo.

Si ha tablas y consultas sanos indexada correctamente, usted podría mirar en partición. .

Editar:

Se puede probar si la adición de índice (pid, author_id) o el índice (author_id, PID) en ibf_posts mesa de ayuda.