J'ai une base de donnée MySQL qui contient 10 000 000 de lignes,
hors celle-ci est TRES TRES LENTE du coup, ai je un moyen d'optimiser cela ?
merci d'avance un peu vague comme question
tout depend aussi de l'architecture de la base de données... les index sont -ils bien places ?? etc...
Arol
"Mag" a écrit dans le message de news:
Bonjour,
J'ai une base de donnée MySQL qui contient 10 000 000 de lignes,
hors celle-ci est TRES TRES LENTE du coup, ai je un moyen d'optimiser cela ?
A part la solution des index, faut voir plus précisément le type des champs. Donc, à éviter au maximum tous les champs du type text, blob etc... et n'avoir que des entiers. Ceci demande un gros boulot de recodage des infos, mais une requête du genre : select * from table where champ_1 = 3 and champ_2 = 2 and champ_3 > 4 est un peu plus rapide qu'une requête du genre select * from table where champ_1 = "Mme" and champ_2 = "entre 15 et 18 ans" and champ_3 > 4
Avec le recodage, non seulement c'est plus rapide, mais en plus la table avec ses 10 000 000 de lignes est plus petite.
"Mag" a écrit dans le message de news:
Bonjour,
J'ai une base de donnée MySQL qui contient 10 000 000 de lignes,
hors celle-ci est TRES TRES LENTE du coup, ai je un moyen d'optimiser cela
?
A part la solution des index, faut voir plus précisément le type des champs.
Donc, à éviter au maximum tous les champs du type text, blob etc... et
n'avoir que des entiers.
Ceci demande un gros boulot de recodage des infos, mais une requête du genre
:
select * from table where champ_1 = 3 and champ_2 = 2 and champ_3 > 4
est un peu plus rapide qu'une requête du genre
select * from table where champ_1 = "Mme" and champ_2 = "entre 15 et 18 ans"
and champ_3 > 4
Avec le recodage, non seulement c'est plus rapide, mais en plus la table
avec ses 10 000 000 de lignes est plus petite.
J'ai une base de donnée MySQL qui contient 10 000 000 de lignes,
hors celle-ci est TRES TRES LENTE du coup, ai je un moyen d'optimiser cela ?
A part la solution des index, faut voir plus précisément le type des champs. Donc, à éviter au maximum tous les champs du type text, blob etc... et n'avoir que des entiers. Ceci demande un gros boulot de recodage des infos, mais une requête du genre : select * from table where champ_1 = 3 and champ_2 = 2 and champ_3 > 4 est un peu plus rapide qu'une requête du genre select * from table where champ_1 = "Mme" and champ_2 = "entre 15 et 18 ans" and champ_3 > 4
Avec le recodage, non seulement c'est plus rapide, mais en plus la table avec ses 10 000 000 de lignes est plus petite.
Sébastien Kirche
Le 26 July 2006 à 20:54, Arol a formulé :
"Mag" a écrit dans le message de news:
Bonjour,
J'ai une base de donnée MySQL qui contient 10 000 000 de lignes,
hors celle-ci est TRES TRES LENTE du coup, ai je un moyen d'optimiser cela ?
A part la solution des index, faut voir plus précisément le type des champs. Donc, à éviter au maximum tous les champs du type text, blob etc... et n'avoir que des entiers. Ceci demande un gros boulot de recodage des infos, mais une requête du genre
select * from table where champ_1 = 3 and champ_2 = 2 and champ_3 > 4
est un peu plus rapide qu'une requête du genre select * from table where champ_1 = "Mme" and champ_2 = "entre 15 et 18 ans" and champ_3 > 4
Avec le recodage, non seulement c'est plus rapide, mais en plus la table avec ses 10 000 000 de lignes est plus petite.
Autant je suis d'accord sur la question des index, autant je le suis beaucoup moins sur le reste de ta réponse : les champs doivent être adaptés aux données à stocker.
Donc quand il faut un champ texte, ben il faut (par contre on peut préférer du varchar à du text). Maintenant il faut voir comment est utilisé la base et le sql, et ton exemple du « where champ_2 = "entre 15 et 18 ans" » m'ouvre des perspectives... C'est du vécu ? À rapprocher d'une sélection utilisant l'opérateur between. Ex: « where age between 15 and 18 »
Au final, on se rend compte que c'est un métier les bdd, et comme le reste on peut facilement faire des trucs atroces si on bricole.
-- Sébastien Kirche
Le 26 July 2006 à 20:54, Arol a formulé :
"Mag" a écrit dans le message de news:
Bonjour,
J'ai une base de donnée MySQL qui contient 10 000 000 de lignes,
hors celle-ci est TRES TRES LENTE du coup, ai je un moyen
d'optimiser cela
?
A part la solution des index, faut voir plus précisément le type des
champs. Donc, à éviter au maximum tous les champs du type text, blob
etc... et n'avoir que des entiers. Ceci demande un gros boulot de
recodage des infos, mais une requête du genre
select * from table where champ_1 = 3 and champ_2 = 2 and champ_3 > 4
est un peu plus rapide qu'une requête du genre select * from table
where champ_1 = "Mme" and champ_2 = "entre 15 et 18 ans" and champ_3 >
4
Avec le recodage, non seulement c'est plus rapide, mais en plus la
table avec ses 10 000 000 de lignes est plus petite.
Autant je suis d'accord sur la question des index, autant je le suis
beaucoup moins sur le reste de ta réponse : les champs doivent être
adaptés aux données à stocker.
Donc quand il faut un champ texte, ben il faut (par contre on peut
préférer du varchar à du text).
Maintenant il faut voir comment est utilisé la base et le sql, et ton
exemple du « where champ_2 = "entre 15 et 18 ans" » m'ouvre des
perspectives... C'est du vécu ? À rapprocher d'une sélection utilisant
l'opérateur between. Ex: « where age between 15 and 18 »
Au final, on se rend compte que c'est un métier les bdd, et comme le
reste on peut facilement faire des trucs atroces si on bricole.
J'ai une base de donnée MySQL qui contient 10 000 000 de lignes,
hors celle-ci est TRES TRES LENTE du coup, ai je un moyen d'optimiser cela ?
A part la solution des index, faut voir plus précisément le type des champs. Donc, à éviter au maximum tous les champs du type text, blob etc... et n'avoir que des entiers. Ceci demande un gros boulot de recodage des infos, mais une requête du genre
select * from table where champ_1 = 3 and champ_2 = 2 and champ_3 > 4
est un peu plus rapide qu'une requête du genre select * from table where champ_1 = "Mme" and champ_2 = "entre 15 et 18 ans" and champ_3 > 4
Avec le recodage, non seulement c'est plus rapide, mais en plus la table avec ses 10 000 000 de lignes est plus petite.
Autant je suis d'accord sur la question des index, autant je le suis beaucoup moins sur le reste de ta réponse : les champs doivent être adaptés aux données à stocker.
Donc quand il faut un champ texte, ben il faut (par contre on peut préférer du varchar à du text). Maintenant il faut voir comment est utilisé la base et le sql, et ton exemple du « where champ_2 = "entre 15 et 18 ans" » m'ouvre des perspectives... C'est du vécu ? À rapprocher d'une sélection utilisant l'opérateur between. Ex: « where age between 15 and 18 »
Au final, on se rend compte que c'est un métier les bdd, et comme le reste on peut facilement faire des trucs atroces si on bricole.
-- Sébastien Kirche
Sébastien Kirche
Le 29 July 2006 à 14:12, Arol a dit :
Maintenant il faut voir comment est utilisé la base et le sql, et ton exemple du « where champ_2 = "entre 15 et 18 ans" » m'ouvre des perspectives... C'est du vécu ?
Oui, c'est un formulaire avec une combo "Votre âge ?". Donc au lieu de coder un truc du genre : 1 => "< à 15 ans" 2 => "entre 15 et 18 ans" 3 => "entre 18 ans et 25 ans" etc... Ils mettent directement l'intitulé.
Arf. Celle là je vais l'encadrer et la montrer aux copains, je n'aurais pas oser imaginer un truc du genre.
J'ai également eu le droit au nom des villes/départements non codifiés. Par exemple stoquer "PARIS" en varchar, au lieu de "75" en smallint
La plus drole, c'est la date sur 5 champs en varchar : 1 champs année, 1 champs mois, 1 champs jour, 1 champs heure, 1 champs minute Alors que le type datetime existe et est très pratique.
Ben oui il existe, et il est même conçu dans ce but.
Au final, on se rend compte que c'est un métier les bdd,
Ben oui
et comme le reste on peut facilement faire des trucs atroces si on bricole.
Dans notre cas particulier, une table avec 10 000 000 de lignes, ça a de forte chances que ce soit une table de log. Et dans quasi tous les logs, ce sont des événements qu'on stoque, donc c'est forcément codifiable avec des entiers.
Quand je demande pourquoi ils ne codent pas les champs, c'est toujours la même réponse : "pour pouvoir lire direct la base de données". Après, j'ai beau expliquer qu'une base de données n'est pas faite pour être lue en brute, mais avec des outils de visualisation, ils répondent "ah non, c'est trop compliqué ça". Après, ils s'étonnent que leur base est lente et trop grosse.
Ouaip, le gros problème c'est le client qui veut une base mais ne connait pas le SQL ou mal.
Je bosse sur un projet de base depuis 2 mois et j'ai eu le même cas : on m'a demandé dans pas mal de tables une colonne inutile qui peut se retrouver en *une* seule jointure sur une table qui relie toutes les tables en question. Quand j'ai demandé la raison on m'a expliqué que c'était pour que la personne qui exploiterait une partie des données puisse faire des extraction et avoir cette info recopiée inutilement. Mais je n'ai encore pas cédé :)
-- Sébastien Kirche
Le 29 July 2006 à 14:12, Arol a dit :
Maintenant il faut voir comment est utilisé la base et le sql, et
ton exemple du « where champ_2 = "entre 15 et 18 ans" » m'ouvre des
perspectives... C'est du vécu ?
Oui, c'est un formulaire avec une combo "Votre âge ?".
Donc au lieu de coder un truc du genre :
1 => "< à 15 ans"
2 => "entre 15 et 18 ans"
3 => "entre 18 ans et 25 ans"
etc...
Ils mettent directement l'intitulé.
Arf. Celle là je vais l'encadrer et la montrer aux copains, je n'aurais
pas oser imaginer un truc du genre.
J'ai également eu le droit au nom des villes/départements non
codifiés. Par exemple stoquer "PARIS" en varchar, au lieu de "75" en
smallint
La plus drole, c'est la date sur 5 champs en varchar :
1 champs année, 1 champs mois, 1 champs jour, 1 champs heure, 1 champs
minute
Alors que le type datetime existe et est très pratique.
Ben oui il existe, et il est même conçu dans ce but.
Au final, on se rend compte que c'est un métier les bdd,
Ben oui
et comme le
reste on peut facilement faire des trucs atroces si on bricole.
Dans notre cas particulier, une table avec 10 000 000 de lignes, ça a
de forte chances que ce soit une table de log. Et dans quasi tous les
logs, ce sont des événements qu'on stoque, donc c'est forcément
codifiable avec des entiers.
Quand je demande pourquoi ils ne codent pas les champs, c'est toujours
la même réponse : "pour pouvoir lire direct la base de données".
Après, j'ai beau expliquer qu'une base de données n'est pas faite pour
être lue en brute, mais avec des outils de visualisation, ils
répondent "ah non, c'est trop compliqué ça". Après, ils s'étonnent que
leur base est lente et trop grosse.
Ouaip, le gros problème c'est le client qui veut une base mais ne
connait pas le SQL ou mal.
Je bosse sur un projet de base depuis 2 mois et j'ai eu le même cas : on
m'a demandé dans pas mal de tables une colonne inutile qui peut se
retrouver en *une* seule jointure sur une table qui relie toutes les
tables en question. Quand j'ai demandé la raison on m'a expliqué que
c'était pour que la personne qui exploiterait une partie des données
puisse faire des extraction et avoir cette info recopiée inutilement.
Mais je n'ai encore pas cédé :)
Maintenant il faut voir comment est utilisé la base et le sql, et ton exemple du « where champ_2 = "entre 15 et 18 ans" » m'ouvre des perspectives... C'est du vécu ?
Oui, c'est un formulaire avec une combo "Votre âge ?". Donc au lieu de coder un truc du genre : 1 => "< à 15 ans" 2 => "entre 15 et 18 ans" 3 => "entre 18 ans et 25 ans" etc... Ils mettent directement l'intitulé.
Arf. Celle là je vais l'encadrer et la montrer aux copains, je n'aurais pas oser imaginer un truc du genre.
J'ai également eu le droit au nom des villes/départements non codifiés. Par exemple stoquer "PARIS" en varchar, au lieu de "75" en smallint
La plus drole, c'est la date sur 5 champs en varchar : 1 champs année, 1 champs mois, 1 champs jour, 1 champs heure, 1 champs minute Alors que le type datetime existe et est très pratique.
Ben oui il existe, et il est même conçu dans ce but.
Au final, on se rend compte que c'est un métier les bdd,
Ben oui
et comme le reste on peut facilement faire des trucs atroces si on bricole.
Dans notre cas particulier, une table avec 10 000 000 de lignes, ça a de forte chances que ce soit une table de log. Et dans quasi tous les logs, ce sont des événements qu'on stoque, donc c'est forcément codifiable avec des entiers.
Quand je demande pourquoi ils ne codent pas les champs, c'est toujours la même réponse : "pour pouvoir lire direct la base de données". Après, j'ai beau expliquer qu'une base de données n'est pas faite pour être lue en brute, mais avec des outils de visualisation, ils répondent "ah non, c'est trop compliqué ça". Après, ils s'étonnent que leur base est lente et trop grosse.
Ouaip, le gros problème c'est le client qui veut une base mais ne connait pas le SQL ou mal.
Je bosse sur un projet de base depuis 2 mois et j'ai eu le même cas : on m'a demandé dans pas mal de tables une colonne inutile qui peut se retrouver en *une* seule jointure sur une table qui relie toutes les tables en question. Quand j'ai demandé la raison on m'a expliqué que c'était pour que la personne qui exploiterait une partie des données puisse faire des extraction et avoir cette info recopiée inutilement. Mais je n'ai encore pas cédé :)
-- Sébastien Kirche
JustMe
=?iso-8859-15?Q?Sébastien?= Kirche a écrit
m'a demandé dans pas mal de tables une colonne inutile qui peut se retrouver en *une* seule jointure sur une table qui relie toutes les tables en question. Quand j'ai demandé la raison on m'a expliqué que c'était pour que la personne qui exploiterait une partie des données puisse faire des extraction et avoir cette info recopiée inutilement. Mais je n'ai encore pas cédé :)
Créé lui des vues
=?iso-8859-15?Q?Sébastien?= Kirche a écrit
m'a demandé dans pas mal de tables une colonne inutile qui peut se
retrouver en *une* seule jointure sur une table qui relie toutes les
tables en question. Quand j'ai demandé la raison on m'a expliqué que
c'était pour que la personne qui exploiterait une partie des données
puisse faire des extraction et avoir cette info recopiée inutilement.
Mais je n'ai encore pas cédé :)
m'a demandé dans pas mal de tables une colonne inutile qui peut se retrouver en *une* seule jointure sur une table qui relie toutes les tables en question. Quand j'ai demandé la raison on m'a expliqué que c'était pour que la personne qui exploiterait une partie des données puisse faire des extraction et avoir cette info recopiée inutilement. Mais je n'ai encore pas cédé :)
Créé lui des vues
Sébastien Kirche
Le 29 July 2006 à 17:23, JustMe vraute :
Mais je n'ai encore pas cédé :)
Créé lui des vues
J'ai eu l'idée au moment où je rédigeais le message précédent. Je crois que ça permettra de ménager la chèvre et le chou : ma base reste correcte et l'utilisateur qui ne connaît pas les jointures est content. -- Sébastien Kirche
Le 29 July 2006 à 17:23, JustMe vraute :
Mais je n'ai encore pas cédé :)
Créé lui des vues
J'ai eu l'idée au moment où je rédigeais le message précédent. Je crois
que ça permettra de ménager la chèvre et le chou : ma base reste
correcte et l'utilisateur qui ne connaît pas les jointures est content.
--
Sébastien Kirche
J'ai eu l'idée au moment où je rédigeais le message précédent. Je crois que ça permettra de ménager la chèvre et le chou : ma base reste correcte et l'utilisateur qui ne connaît pas les jointures est content. -- Sébastien Kirche
