Bonjour,
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Bonjour,
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Bonjour,
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Le 16 Nov 2010 10:54:49 GMT,
Kevin Denis écrivait :Bonjour,
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
Le 16 Nov 2010 10:54:49 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait :
Bonjour,
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
Le 16 Nov 2010 10:54:49 GMT,
Kevin Denis écrivait :Bonjour,
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Le 16-11-2010, Sebastien Lardiere a écrit :j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Le 16-11-2010, Sebastien Lardiere <sebastien.lardiere@free.fr> a écrit :
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Le 16-11-2010, Sebastien Lardiere a écrit :j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
On 11/16/2010 12:29 PM, Kevin Denis wrote:Le 16-11-2010, Sebastien Lardiere a écrit :j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
dans
un OS décent,
une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
On 11/16/2010 12:29 PM, Kevin Denis wrote:
Le 16-11-2010, Sebastien Lardiere<sebastien.lardiere@free.fr> a écrit :
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
dans
un OS décent,
une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
On 11/16/2010 12:29 PM, Kevin Denis wrote:Le 16-11-2010, Sebastien Lardiere a écrit :j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
dans
un OS décent,
une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
bonjour,
Le 16/11/2010 13:54, Sebastien Lardiere a écrit :On 11/16/2010 12:29 PM, Kevin Denis wrote:Le 16-11-2010, Sebastien Lardiere a
écrit :j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les
indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
dans
un OS décent,
ça existe ???une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du
SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la
table...
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
A +
bonjour,
Le 16/11/2010 13:54, Sebastien Lardiere a écrit :
On 11/16/2010 12:29 PM, Kevin Denis wrote:
Le 16-11-2010, Sebastien Lardiere<sebastien.lardiere@free.fr> a
écrit :
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les
indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
dans
un OS décent,
ça existe ???
une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du
SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la
table...
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
A +
bonjour,
Le 16/11/2010 13:54, Sebastien Lardiere a écrit :On 11/16/2010 12:29 PM, Kevin Denis wrote:Le 16-11-2010, Sebastien Lardiere a
écrit :j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
Drop index ?
oui, drop index :
http://dev.mysql.com/doc/refman/5.1/en/drop-index.html
Merci.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les
indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
dans
un OS décent,
ça existe ???une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du
SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la
table...
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
A +
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
> Quand à MySQL, ce que j'en pense a été résumé ici :
> http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne
voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au
contraire.
> Quand à MySQL, ce que j'en pense a été résumé ici :
> http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne
voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au
contraire.
> Quand à MySQL, ce que j'en pense a été résumé ici :
> http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne
voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au
contraire.