[MySQL] Besoin d'aide - Optimisation d'une requête très lourde

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [MySQL] Besoin d'aide - Optimisation d'une requête très lourde

nero27

Reprise du message précédent :

Beegee a écrit :

Ce serait intéressant de savoir combien il y a de lignes dans chaque table (40 millions pour action_historique, mais combien pour les autres tables : membre/chval ?)

edit: et une approximation du nombre de lignes qu'on pense effacer.

Environ 150 000 pour membre et 190 000 pour chval.
Il y a, je pense quelques centaines d'enregistrements à effacer.

Pour info, la version de MySQL est la 4.1.13
Le serveur est un bi-Xeon (2.8 ou 3GHz, je ne sais plus) avec 2Go de RAM, SCSI+Raid1.

Message édité par nero27 le 20-09-2005 à 14:40:20

Publicité

Arjuna

Aircraft Ident.: F-MBSD

c'est criminel de mettre un sgbd aussi pourri sur un aussi joli serveur :cry:

(quoique vous auriez quand même pu mettre du RAID 5+0 )

Message cité 1 fois
Message édité par Arjuna le 20-09-2005 à 14:51:47

nero27

Arjuna a écrit :

c'est criminel de mettre un sgbd aussi pourri sur un aussi joli serveur :cry:

(quoique vous auriez quand même pu mettre du RAID 5+0 )

On a pas non plus la fortune à Rothschild

Message cité 1 fois

Beegee

On peut voir des plans d'exécution sous un mySql récent ? ou c'est toujours une boîte noire ?

tomlameche

Et pourquoi pas ?

Arjuna a écrit :

Ben chais pas, quand j'étais chez GE (avec un Serveur HP sous SunOS / Oracle 8i) la création d'un index était rigoureusement instantannée (ou ça prenait une petite dizaine de secondes).
Puis ensuite si on faisait une requête tapant normalement dans l'index, il ne l'utilisait pas. Avec un table hint, on obtenait une erreur comme quoi l'index n'était pas prêt.
Puis au bout de quelques minutes ça marchait.

Par contre, maintenant que tu m'y fait penser c'est vrai que... il fallait faire une oppération spéciale pour que ça marche... me souvient plus du tout quoi ! Parceque dans TOAD ça mettait un peu plus de temps. Et vu que la machine était quelque peut grosse (pintaprocesseur - me demandez pas pourquoi 5 et pas un multiple de deux avec deux SAN dédiés aux bases et quelque 4 Go de mémoire par CPU) donc forcément, même un index sur 25 champ sur une table de 50 000 000 lignes ça mettait pas très longtemps à se créer...
M'enfin sur et certain, dans notre batch de réplication de la base depuis le serveur de l'ERP vers la base dédiée au Web, via SQL Loader, (suppression des index, truncate, allimentation puis indexation), l'indexation qui suivait était rigoureusement instantannée, et pourtant le volume des données était pire (dénormalisation et duplication des valeurs de référence pour de meilleures performances en lecture) alors que le serveur était... le même

Ben mince alors, j'ai du passer à coté d'amélioration de perf notable dans certains projet, j'ai souvenir de phase de création d'index d'un bon 1/4 d'heure pour des tables d'une dizaine de million pas plus
Ceci dit, ça devrait pas changer grand chose en temps total au final, la plupart du temps c'etait pour utilisation de la table et des indexes immédiatement après.

---------------
Gérez votre collection de BD en ligne ! ---- Electro-jazzy song ---- Dazie Mae - jazzy/bluesy/cabaret et plus si affinité

Beegee

De toute façon ça sert pas à grand chose la création d'index en background ... en tout cas ça n'apporte rien par rapport à un script qui contient le CREATE INDEX et qu'on lance en tâche de fond !

Message cité 1 fois

Arjuna

Aircraft Ident.: F-MBSD

nero27 a écrit :

On a pas non plus la fortune à Rothschild

ben alors faites tourner ça sur une machine digne du moteur de MySQL, un Goupil avec 128 Ko de RAM

Arjuna

Aircraft Ident.: F-MBSD

Beegee a écrit :

Ben si, ça permet d'avoir des batchs qui ne se tapent pas un timeout au bout d'une heure d'éxécution

casimimir

sinon un fois que tu as mis tes index sur les champs idc et idm de ta table historique, tu peux y aller en bourrinant avec des tables temporaires explicites.
un truc genre

Code :

drop ma_table_temp;
create ma_table_temp as select idm from(
select idm from member group by idm
minus
select idm from action_historique group by idm);
delete from action_historique where idm in (select idm from ma_table_temp);

c'est basique, c'est bourrin, on pourrait croire que ca fait exactement la même chose, mais d'expérience ca permet d'accélerer le traitement dans certains cas ou le sgbd pète un peu les plombs et s'atomise lui-même pour des raisons obscures

Message édité par casimimir le 21-09-2005 à 11:55:57

Beegee

Ou le contraire, avec un IN ... enfin faut tester quoi, parce mySql montre pas trop ce qu'il fait

Publicité

casimimir

euhhh oui c'est un in en fait, je corrige

nero27

Ok, merci pour vos conseils : les index sont en place et je pense que je vais passer par une table temporaire ^^

dabratt

Moi à ta place je remplacerais les NOT IN par des IN avec des MINUS, si tu vois ce que je veux dire....

Message cité 1 fois

Arjuna

Aircraft Ident.: F-MBSD

Juste en passant : pour le CREATE INDEX, j'ai du créer un index portant sur 300 000 000 de lignes l'autre jours sous Oracle 9i (je crois). Et ça a mis 3 plombes. Etrange... A moins que chez GE leurs serveurs étaient tellement énorme que quelques secondes suffisaient à créer de tels index (ce qui ne m'étonnerais pas vu la tronche des machins)

betsamee

Asterisk Zeperyl

dabratt a écrit :

Moi à ta place je remplacerais les NOT IN par des IN avec des MINUS, si tu vois ce que je veux dire....

pas de MINUS EN MySQL
extrait de la doc:

Citation :

1.6.5 Ce qui est prévu à moyen terme
.....
MINUS, INTERSECT et FULL OUTER JOIN. (actuellement, UNION [en 4.0] et LEFT OUTER JOIN fonctionnent).
....

dabratt

Bon bah sous Oracle c'est comme cela que je l'aurais fait

Message cité 1 fois

betsamee

Asterisk Zeperyl

dabratt a écrit :

Bon bah sous Oracle c'est comme cela que je l'aurais fait

pas besoin du
ca me fait chier a moi aussi que ca existe pas

dabratt

Quelle idée d'utiliser MySql sur ce volume de données

casimimir

arjuna: pour le create index je ne sais pas si tu mets un nologing a la fin mais ca aide

globalement je fais pratiquement un nologing compute statistics si je les crée de rien

Arjuna

Aircraft Ident.: F-MBSD

moi je fais que dalle, je laisse le boulot aux dba s'ils veulent des optimisations particulières :

create index uix_csk_wv_controlestocks
on csk (...)
tablespace pri_ix

Après, je laisse le dba paramètrer les comportements par défaut d'Oracle lors de l'éxécution de la commande : spa mon métier, et si je fais mieu que lui, il va faire la gueule, et si je fait moins bien, ça va me retomber dessus :spamafote:

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

SQL/NoSQL

[MySQL] Besoin d'aide - Optimisation d'une requête très lourde

Sujets relatifs
[réglé]Besoin d'aide avec SQL d'Oracle	Probleme de requete et de texte en php [Résolu, euh en fait non]
Besoin de conseils pour oracle 10g	url rewriting... besoin de conseils pour ma page
Pb "too connection" a mon serveur mysql	Resultat d'une requete parametre dans zone de liste !!
petit pb requete	Probleme de requete
MySQL aide pour select
Plus de sujets relatifs à : [MySQL] Besoin d'aide - Optimisation d'une requête très lourde

Page générée en 0.040 secondes