Base de données lente récupération / mise à jour / insertion problème avec plus de 5 enregistrements de mil dans chaque table

Question

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

Actuellement, j'ai base de données avec plus de 5milion enregistrements dans une table qui provoque la récupération de données lente. Je recherche actuellement des moyens de base de données de la structure pour éviter ce genre de base de données. (Base de données du moteur MyISAM)

Les tableaux qui causent des problèmes sont des postes et des commentaires ayant plus de dossiers 5mil dans chaque.

J'ai eu une idée lors de l'utilisation de fichier texte de stockage lors de l'enregistrement des documents par date, afin que chaque fichier contenait suffisamment de données qui n'a pas été ralentit la récupération et les processus d'économie, mais avec des bases de données, je ne sais pas quoi faire: (

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

Structure "messages"

    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 tant que ça.

Vous avez probablement indexé la mauvaise table.

S'il vous plaît poster votre requête et nous vous dirons 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

Aussi, vous omettez la clause ORDER BY mais cette clause est trop importante, l'utilisation des index peut améliorer aussi bien.

Answer 2

PLAN EXPLIQUER vous dira comment le moteur de recherche est fait. Si vous voyez « scan de table », vous savez que vous avez besoin d'index.

Answer 3

5 M lignes dans une table est pas tant que ça, combien de temps vos requêtes prennent? Je soupçonne que vous pourriez avoir quelques problèmes avec l'indexation. EXPLAIN peut aider à savoir ce que vous requêtes sont en train de faire.

Si vous avez correctement tables indexées et requêtes sain d'esprit, vous pouvez regarder dans partitionnement. .

Edit:

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