mysql optimisation de requete "is not null"

bonjour à tous

j'ai une table qui contient environ 2 millions d'enregistrements
avec un champs "id", "nom" et plusieurs autre champs numéroté de 1 à 20


je fais dans cette table des requêtes du style

Code:

---

1 2 3 4

select ... where nom='toto' and champ11 is not null and champ12 is not null order by id

---

en fait je cherche la présence d'information dans le champ11 ET le champ12 pour le nom toto. Le problème c'est que les champ1 à champ20 ne sont pas indexé (je pense que d'indexé individuellement tout les champs est contre productif) et donc les perfs ne sont pas très bonne.

je vois pas trop comment m'en sortir : une idée ?

Si tu nous disais plus concrètement de quoi il s'agit, on pourrait mieux t'aider.
Tout ce que je peux faire avec aussi peu d'infos, c'est de t'aiguiller vers les articles de SQLPro sur l'indexation :
http://sqlpro.developpez.com/cours/quoi-indexer/
http://sqlpro.developpez.com/optimis...ntenanceIndex/
http://blog.developpez.com/sqlpro/p7...d-index-ni-de/

Mais si tu as autant de colonnes (et pas de champs ! :roll:) qui sont potentiellement à NULL, fsmrel te dirait qu'il vaut mieux revoir ton modèle de données.
Voir cette autre discussion à partir de mon message qui parle des NULL.

tant qu'a mettre des liens...
http://fr.wikipedia.org/wiki/Champ_%...onn%C3%A9es%29

je connais bien l'indexation, j'utilise des bases de données depuis plus de 10 ans.

mon modèle de données est cohérent, il correspond à différent fichiers hétérogènes contenant (ou non) de l'information sur certains critères. Cette table permet de normaliser ces informations.

Ma question est de savoir si je dois indexer les "colonnes" individuellement pour augmenter la rapidité d'exécution de mes requêtes sachant qu'elles utilisent 1 ou 2 colonnes de manière non déterministe dans la clause WHERE. Je ne veux pas créer 1 index par colonne de peur "d'exploser" la taille totale des index, mais je me doute que de ne pas en mettre n'est pas mieux. En fait je cherche un compromis (performance lecture/rapidité d'insertion).

Citation:

---

Envoyé par austin P.

tant qu'a mettre des liens...
http://fr.wikipedia.org/wiki/Champ_%...onn%C3%A9es%29

---

Merci pour le lien ; j'ai commencé à corriger l'article en question, ainsi que celui consacré aux tables de bases de données mais il y a encore du boulot ! 8O

Citation:

---

mon modèle de données est cohérent, il correspond à différent fichiers hétérogènes contenant (ou non) de l'information sur certains critères. Cette table permet de normaliser ces informations.

---

Mouais... c'est toi qui le dit... difficile d'en juger avec aussi peu d'informations. :?

Citation:

---

Ma question est de savoir si je dois indexer les "colonnes" individuellement pour augmenter la rapidité d'exécution de mes requêtes sachant qu'elles utilisent 1 ou 2 colonnes de manière non déterministe dans la clause WHERE. Je ne veux pas créer 1 index par colonne de peur "d'exploser" la taille totale des index, mais je me doute que de ne pas en mettre n'est pas mieux. En fait je cherche un compromis (performance lecture/rapidité d'insertion).

---

Fait des tests.
Prends les cas de recherche les plus fréquents. Essaie les requêtes avec et sans index et vois la différence. Ajoute les index petit à petit et vois à quel moment ça devient contre-performant.

Citation:

---

Mouais... c'est toi qui le dit... difficile d'en juger avec aussi peu d'informations.

---

en fait cette table correspond à une représentation à plat de mes fichiers. C'est une table temporaire et elle est nettoyée à chaque importation. En langage imagée, elle est un point de passage entre 2 mondes. Le problème vient plus de la très grande quantité d'information que j'y stocke le temps de mon traitement.

je viens de faire des tests en positionnant un index sur chaque champ de la table (champs1 à champs20). Évidemment les requêtes sont rapides (sur le critère IS NOT NULL), malheureusement (et c'est ce que je craignais) la taille de l'index équivaut à celui de la table. Pourtant en créant un index de taille 1 je pensait éviter cela.

Code:

---

1 2	ALTER TABLE MATABLE ADD INDEX 'champ1'('champ1'(1))...

---

ma question initiale était justement de trouver un index/une technique me permettant de requeter les "not null" rapidement sans pour autant que cet index devienne énorme car j'imagine que cela vas fortement ralentir la phase d'insertion de données.

Citation:

---

Envoyé par austin P.

ma question initiale était justement de trouver un index/une technique me permettant de requeter les "not null" rapidement sans pour autant que cet index devienne énorme car j'imagine que cela vas fortement ralentir la phase d'insertion de données.

---

Si ce sont des insertions en masse, tu peux :
1) désactiver les index
2) faire ton insertion en masse (LOAD DATA INFILE est notamment très rapide)
3) réactiver les index

Ainsi les index ne sont recréés qu'en une seule fois.
D'ailleurs, je ne suis même pas sûr qu'avec LOAD DATA INFILE l'opération sur les index ne soit pas justement automatique. A vérifier dans la doc MySQL peut-être.

oui c'est pas mal mais ça risque de pas coller car cette insertion se fait dans un processus java qui lit les fichiers, décortique les éléments, insère dans la base etc...

je continue de chercher pour trouver une solution viable
merci pour tes réponses