MySQL améliorer les performances de grandes tables

Question

Je suis nouveau sur MySQl. S'il vous plaît excusez de mauvaises terminologies. J'ai une question sur l'indexation et le fractionnement des tables dans MySQL. Je travaille sur un serveur web. Il y a 3 très grandes tables qui sont fréquemment interrogées. Les tables et leurs champs sont les suivants:

Alignement: ali_id, chain1_id, chain2_id .....; Graine: seed_id, ali_id, .....; Fragment: seed_id .......

Seed contient un ou plusieurs enregistrements pour un alignement donné. Fragment contient un ou plusieurs enregistrements pour Seed.

La taille des tables à la convergence - 8.3GB, semences - 26FR et le fragment - 127 Go

Ces tableaux ont des indices très importants: L'alignement doit indice chain1_id, chain2_id, ali_id, (chain1_id et chain2_id) et (chain2_id et chain1_id). Par conséquent, la taille du fichier d'index lui-même est de 27G, ce qui représente environ 3 fois la taille de la table d'alignement.

Est-ce approprié?

De plus, comme la taille de la table devient très importante, le serveur continue de se bloquer. Est-ce une bonne idée de diviser les tables en plus petites. Je suis confus parce que je ne suis pas sûr si plusieurs instructions select ralentiront également le serveur.

Merci.

Cordialement, Amit.

tableaux ont déjà été créées par une personne else.I suppose qu'ils étaient comme suit:

create Table Alignment (
ali_id int(11) PRIMARY KEY, 
chain_id1 int(11), 
chain_id2 int(11), 
param_id smallint(6), 
date datetime); 

create Table Seed(
seed_id int(11), 
Ne smallint(5), 
rmsd float, 
ali_id int(11), 
identics smallint(6)); 

* Seed has 5 more fields, all are smallint(6) 

create table Fragment (
start1 smallint(6), 
start2 smallint(6), 
len smallint(6), 
seed_id bigint(20)); 

Il requête qui prend beaucoup de temps est:

select a.chain_id2, s.Ne, s.rmsd, s.zN, s.ali_id, s.identics, s.positives, s.nFrg, s.cMatch, s.cont1, s.cont2, s.bMatch, s.back1, s.back2, s.seed_id 

from Alignment AS a, Chain AS c, Seed AS s 

WHERE (a.chain_id1 = c.chain_id) and a.ali_id = s.ali_id and c.pdb_chain = "$pdb_here" and s.zN > $ZLIM; 

Le nombre de visites peut varier de 100- 2000

Il est exécuté sur un serveur Apache sur une machine Linux avec Intel Quad Core à 2,5 GHz avec 4 Go de RAM.

Answer 1

Je suppose que votre base de données n'a pas été optimisée. En MySQL, vous pouvez reconstruire des index, vous pouvez optimiser la table, vous pouvez exécuter quelques-uns des états de maintenance de table [1]

[1] http://dev.mysql.com/doc/refman/5.1/fr /table-maintenance-sql.html

L'étape suivante, vu que vos données peuvent augmenter de façon exponentielle.
Jetez un oeil à http://www.mysql.com/products/cluster/, voyez si vous pouvez vous y préparer aussi.

Answer 2

Ne vous préoccupez pas de la taille des tables. Il devrait ne pas causer de problèmes si vous vous assurez que les index sont correctement mis en place. De plus, vous voulez vous assurer que toute information redondante est stockée dans une base de données séparée. Vous pouvez facilement le récupérer via une requête JOIN. Si votre serveur continue de se bloquer, il n'est pas assez capable de gérer la charge (avec des bases de données aussi importantes, je suppose que vous avez aussi une charge de visiteur importante) ou vous avez des problèmes matériels (un disque dur défectueux). , par exemple). En outre, vos requêtes peuvent nécessiter une optimisation. Les requêtes lentes peuvent bloquer votre table pendant de longues périodes, mettre de nouvelles requêtes en attente ... et bien, tout scénario suivant n'est pas bon.

Answer 3

partition la table serait le point de départ évident