Retard de la base de données/mise à jour/insertion d'un problème avec plus de 5mil d'enregistrements dans chaque table

Question

Comment structurer la base de données pour éviter les ralentissements? (Moteur: MyISAM)

Actuellement, j'ai une base de données avec plus de 5 millions d'enregistrements dans une table qui provoque une récupération lente des données. Je suis actuellement à la recherche de moyens de structurer la base de données pour éviter ce type de base de données. (Moteur de base de données MyISAM)

Les tables qui causent des problèmes sont les publications et les commentaires ayant plus de 5 mil d'enregistrements dans chacun. J'ai eu une idée lors de l'utilisation du fichier texte comme stockage lors de la sauvegarde des enregistrements par date, de sorte que chaque fichier contient suffisamment de données qui ne ralentissaient pas la récupération et l'enregistrement des processus, mais avec les bases de données je ne sais pas quoi faire :(

Est-il possible d'enregistrer des données (environ 5mil enregistrements chacun) dans la base de données MySQL de ne pas provoquer la récupération lente, l'insertion ou la mise à jour des données

« messages » Structure

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; 

requête:?

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'est pas beaucoup.

Vous avez probablement indexé la table incorrectement.

Veuillez publier votre requête et nous vous expliquerons probablement comment l'améliorer.

Mise à jour:

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 

Assurez-vous que:

• members.id est un PRIMARY KEY
• member_extra.id est un PRIMARY KEY
• Vous avez un index sur profile_portal.pp_member_id

Vous avez également omis la clause ORDER BY mais cette clause est également importante, l'utilisation d'index peut également l'améliorer.

Answer 2

EXPLAIN PLAN vous dira comment le moteur de recherche le fait. Si vous voyez "scan de table", vous savez que vous avez besoin d'index.

Answer 3

5M lignes dans une table ne sont pas beaucoup, combien de temps vos requêtes prennent? Je soupçonne que vous pourriez avoir des problèmes avec l'indexation. EXPLAIN instruction peut aider à savoir ce que vous faites réellement des requêtes.

Si vous avez correctement indexé des tables et des requêtes saines, vous pouvez regarder dans partitioning..

Edit:

Vous pouvez essayer si l'ajout d'INDEX (pid, author_id) ou INDEX (author_id, pid) sur ibf_posts de table aide.