Voila l'état de ma base de données
 

 
C'est donc une base qui sert de monitoring et vous pouvez voir ke la table windows 2000 est relativement énorme.
 
bref, dans l'interface php j'ai une page ki permet d'afficher la table windows 2000 (avec un LIMIT bien sur) sur plusieurs pages. Sur chaque page j'affiche 100 lignes de la table (pour la nieme page, la requete qui permet d'avoir les 100 niemes lignes est : select * from W2K LIMIT n*100, 100; )
sur cette meme page j'ai un formulaire qui permet de faire une selection sur différents champs de la table avt d'afficher la table :
 

 
les champs Event Log, Event Type et Event Source sont remplis via une requete SQL qui s'applique sur la table W2K (select distinct eventlog from W2K, et pareil pour le reste)
 
bref etant donné que la table possède plus de 4 000 000 de lignes faire un select distinct dessus c long
meme le select avec le LIMIT (alors kil ne prends ke 100 lignes) est super lent.
 
est ce ke ya moyen d'optimiser tout ca
 
car la page est quasi innaccessible now, c trop lent
 
pour l'instant comme solution temporaire
g backupé la table W2K pour garder les 2go de log et j'ai supprimé le contenu donc maintenant ke ya moins d'entrées c plus rapide mais j'aimerais pas a faire cette manip tous les 3 mois. (temps kil fo pour atteindre 4 500 000 lignes).
 
ya moyen d'optimiser ca ?
 
Edit : je viens de lire un article d'optimisation ki parle d'index et ca a l'air vachement puissant
je vais me renseigner dessus

je plante un drapeau : sujet tres interressant

Déjà, première chose à faire : foutre des index sur les champs souvent accédés en lecture (ca ralentit les requêtes d'update/insert). ensuite, faut voir ton schéma de base et les requêtes que tu fais dessus et là commence la vraie optimisation où on compte des probabilités et tout ça machin...  

k je vais voir ca

c'est n'importe quoi cette table...
faut creer des tables pour les types, les log, et sources :|
select distinct... n'importe quoi :| ca devrait etre banni ce mot clé.
 
EDIT: la complexité de la fonction c'est nombre_de_type*nb_lignes, si t'as 10 types, t'auras 40 millions de comparaisons    
 
tu les connais à l'avance les types, et si ce n'est pas le cas, tu peux les récupérer sur les updates. quand t'as un nouveau type, hop tu l'ajoutes
 
contrainte d'intégrité référencielle:
[numtype, nomtype] => [numlog, log, numtype]
etc...
 
et il est évident qu'un select sur une table de 4 millions de lignes c'est n'importe quoi ... tu devrais faire une table par semaine à ce niveau là, et te démerder ensuite avec la couche métier (php)
 
EDIT2: factorise les données : évite toutes les redondances, je suis sur qu'on peut diviser par 100 la taille de ta table (redondance des messages de log, je parie qu'ils se ressemblent tous)

plutot de dire ke je fait ke dla merde
dit juste ce kil fo pour améliorer la chose koi
 
bref ouais j'avais pas pensé a faire une table pour les types

ok...
balance le contenu d'une dixaine d'enregistrements, histoire de voir ce qu'on peut faire.

oki

donc la on voit le monitoring du serveur VPN
d'ailleur on voit ma connexion dessus (pymaunier)

selon toi il faudirat une table ki contient tous les Event Log, un autre pour les event type, une autre pour les event id ?
 
sinon je découpe la table W2K toutes les 2 semaines

 
moi j ai compri par la qu il voulai voir le contenu de la table ...
a voir si il est possible de creer une table de liaison...

Commençons par le commencement...
Fais une table Event_Log Event_Type (Event_ID ca sert à rien vu que t'as deje des int)
Ensuite le "Text" lui meme tu le mets dans une table a part. Que tu index bien correctement.
 
Avant de faire un insert dans la table Text, tu fais un select pour recuperer l'ID. Si il existe tu gagnes ca au moins dans tes logs (et effectivement souvent ces messages se ressemblent.) Si il existe pas tu cree une entree.
Pareil pour les champs UserName et Computer Name qui passent en table séparée.
Tu vas avoir un gain de place enorme a mon avis. En plus lancer une recherche juste sur des IDs est beaucoup plus rapide que sur du texte...  
 
Donc ta table va etre:
id_table (necessaire pour adresser un log particulier rapidement) bigint auto_increment
datetime
id_computer_name
id_event_log
id_event_type
id_event_source
event_id
id_user_name
id_text
 
table text
id_text
text
 
table computerName
id_computer_name
computer_name
 
etc...

Si je puis me permettre...
Dans les logs il est absolument necessaire de prevoir un systeme de rotation...
 
Ton cas ne fais pas exception
 
Le plus simple etant de changer le nom de ta table principale en nomtable_2004_02
Puis de recreer ta table à l'identique mais à vide... (Esprit logrotate).

merci de ces infos

Posté le 20-02-2004 à 05:31:47   <-- Tu dors pas la nuit???

je jouais a Counter Strike et je voyais pas le temps passer