Database lento recupero / aggiornamento / inserimento di problema con più di 5 record mil in ogni tabella

Question

Come strutturare database per evitare rallentamenti? (Motore: MyISAM)

Attualmente ho database con più di 5milion record in una tabella che provoca lento recupero dei dati. Attualmente sto cercando modi per database di struttura per evitare questo tipo di database. (Database MyISAM Motore)

Le tabelle che causano problemi sono post e commenti con più di record 5mil in ciascuno.

Ho avuto l'idea quando si utilizza file di testo come lo stoccaggio durante il salvataggio di record per data, in modo che ogni file conteneva dati sufficienti che non è stato rallentando il recupero e il salvataggio dei processi, ma con i database non so cosa fare: (

C'è un modo per salvare i dati (circa 5mil record in ciascuna) in database MySQL non causare lento recupero, l'inserimento o l'aggiornamento dei dati?

"messaggi" Struttura

    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;

Domanda:

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 non è molto.

Probabilmente indicizzati tavolo sbagliato.

Si prega di inviare la vostra richiesta e noi probabilmente vi diciamo come migliorarlo.

Aggiornamento:

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

Assicurarsi che:

• members.id è un PRIMARY KEY
• member_extra.id è un PRIMARY KEY
• Hai un indice su profile_portal.pp_member_id

Inoltre è omesso la clausola di ORDER BY ma questa clausola è troppo importante, con indici in grado di migliorare pure.

Answer 2

SPIEGARE PIANO vi dirà come il motore di query sta facendo. Se vedi "tabella di scansione", sai che hai bisogno indici.

Answer 3

righe 5M in una tabella non è più di tanto, per quanto tempo le vostre domande stanno prendendo? Ho il sospetto si possono avere alcuni problemi con l'indicizzazione. SPIEGARE dichiarazione può aiutare a scoprire cosa si query sono in realtà facendo.

Se avete correttamente tabelle e query sane indicizzato, si poteva guardare in partizionamento. .

Modifica:

Si potrebbe provare se l'aggiunta di INDEX (pid, author_id) o INDEX (author_id, PID) sul tavolo ibf_posts aiuta.