Supprimer un index sous mySQL

Le 16 Nov 2010 10:54:49 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait :

Bonjour,

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 ?

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

On 11/16/2010 11:57 AM, JKB wrote:

Le 16 Nov 2010 10:54:49 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait :

Bonjour,

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 ?

oui, drop index :

http://dev.mysql.com/doc/refman/5.1/en/drop-index.html

--
Sébastien

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.

Merci
--
Kevin

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.


--
Sébastien

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 +

--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

SQLpro a écrit :

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... ;-)

MySQL n'achete pas des complesance comme microsoft voir certain arborant
une certif microsoft qui n'est ni plus ni moins qu un pot de vin pour
critiquer les autres

et certain ne sachant pas modelisé une date dans un SGBD s'autoproclame
expert SGBD et le droit de juger MySQL

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...

"polus" ?????

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.

Tout interlocuteur qui n'encense pas dieu Brouard n'est qu'un ignorant

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/

et ce qu'il faut penser de l'auteur est resumé dans le fait qu'il ne
sait pas modelisé une date dans un SGBD

A +

On 11/16/2010 09:57 PM, SQLpro wrote:

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.

De toute façons, à part REINDEX, dans MySQL, il n'existe pas grand chose.

Et je pense qu'il parlait de l'ensemble des index qui est plus gros que
la table. Ce qui est possible, même si ça n'est pas une chose à faire,
amha.

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/

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.

Et puis, à bien des points de vues, l'utilisation et l'administration
d'un systeme est très relatif. Par exemple, dans mon cas ( DBA
PostgreSQL sous Linux), on vient de me coller dans les pattes un MS-SQL
Server, et bien, c'est juste une *HORREUR* à utiliser et à administrer ;
Mais ce n'est qu'une question de point de vue.

--
Sébastien

On 11/17/2010 10:24 AM, Sebastien Lardiere wrote:

> 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.

Bon, j'ai lu un peu plus loin, et ce que vous dites est surement vrai (
je ne vais pas tout vérifier ), le seul point qui ne va pas, c'est que
tout ce que vous dites, les utilisateurs de MySQL s'en contre-foutent,
dans les grandes largeurs, vous n'imaginez même pas. Certains ne savent
même pas ce qu'est une clé primaire ...

Et même des utilisateurs de SQL-Server ou Oracle ou DB2 ( que j'ai migré
à PostgreSQL ) n'utilisait pas 10% des fonctionnalités que vous décrivez.

Je n'ai jamais vu de CTE chez mes clients, par exemple, ou d'index sur
une expression ... Bon évidemment, j'intervenais chez ceux qui avaient
des problèmes avec leur SGBD, pas chez ceux qui maitrisaient.

C'est dommage, j'en suis bien convaincu. Amha, vous perdez du temps à
écrire des articles comme celui-là ; Ceux qui "choisissent" MySQL n'en
ont rien à faire ...

--
Sébastien