Base de datos retriving lenta / actualizar / insertar problema con más de 5mil registros de cada tabla
-
21-09-2019 - |
Pregunta
¿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
Solución
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 unPRIMARY KEY
-
member_extra.id
es unPRIMARY 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.
Otros consejos
Explain Plan le dirá cómo el motor de consulta está haciendo. Si ve "exploración de tabla", usted sabe que necesita índices.
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.