Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Index sur Tables non utilisées
Bonjour,
Je viens de sauvegarder des tables de plusieurs Gigao Octets, ou plutôt renommées. Ces tables ont des index et ne seront plus utilisées , juste histoire d'avoir des backups au cas où.
Vu que ces tables ont des index, vont'elles occupées de l'espace mémoire ? Ou bien uniquement lorsqu'elles sont utilisées ? Je pense qu'elles vont prendre quand même de l'espace mémoire, mais je pose la question histoire de lever mon léger doute
Merci beaucoup
Un index étant une redondance de certaines informations de la table, il prend au moins autant d'espace que les informations qui y sont stockées + une petit volume supplémentaire de données nécessaire à la navigation dans les données de recherche et un autre petit volume pour référencer la ligne originale de la table
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
merci
L'espace occupé est d'autant plus grand que les colonnes des index sont larges et nombreuses et que l'index est multiple.
du mieux : un index PK sur une colonne unique de type integer (voire small integer)
au pire : un index multiple sur plusieurs colonnes de type (var)char
et encore pire : les index full-text
bonjour
Pour être sur qu'il n'y ait pas d'incompréhension :
La table et ses indexes vont certes occuper de l’espace sur le disque, mais ne devrait plus plus occuper d'espace en RAM si elles ne sont plus du tout utilisées...
Salut à tous.
Ce que vous entendez par sauvegarde, est floue !Envoyé par omelhor
S'agit-il d'un utilitaire (un backup) qui effectue la recopie de votre disque dur ?
Ou bien utilisez-vous mysqldump (une sauvegarde) afin d'avoir un script sql ?
Je recommande de désactiver les index de votre base de données lors du chargement de la base de données.
Puis de réactiver ceux-ci quand le chargement sera terminée. Leur recréation se fera automatiquement et va vous faire gagner du temps.
Je suppose que vous parlez d'un backup. Dans ce cas là, la réponse est OUI.
Pour pouvoir utiliser un index, celui-ci doit exister aupréalable.
Et de ce fait, un index va occuper de la place.
@+
Si les tables ont été recopiées pour archiver des données à fin de backup uniquement (pas de consultation) j'ai envie de dire que vous pouvez vous lâcher sur le DROP INDEX… aucun intérêt de conserver des index qui ne servent à rien.
Par contre, si c'est une table d'archive, qui peut être consultée, alors au contraire, il faut revoir les index et vérifier qu'ils correspondent bien aux besoins d'interrogation.
Ceci est généralement faux....
En effet, la reconstruction d'index est un processus qui demande un tri des données et qui est consommateur de ressources et de temps...
Si le CPU est peu véloce et comme MySQL ne sait pas faire du parallélisme, le coût en temps de la reconstruction des index peut être très supérieur à une restauration globale, tables et index....
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Salut SQLPRO.
Je ne suis pas d'accord avec vous. Donc vous préférez, lors d'une restauration d'une table, que les index soient activées.
Je peux vous assurer que cela va prendre un temps bien plus long puisque à chaque insertion, il y aura réorganisation de la table.
Surtout si les lignes ne se présentent pas dans l'ordre de l'index cluster (celui de la primary key, puisque MySql ne fait pas la distinction).
Le mieux est de trier les lignes avant de les charger, et d'activer les index quand la table est totalement chargée.
@+
Dans la mesure où la sauvegarde se fait probablement dans l'ordre physique des données (donc selon l'ordre de l'index cluster), et que la restauration... va évidement se faire dans le même ordre que la sauvegarde, alors il ne va pas y avoir de fragmentation ni de besoin de réorganiser les lignes déjà écrites sur le disque (ce qui est le plus consommateur de tout).Salut SQLPRO.
Je ne suis pas d'accord avec vous. Donc vous préférez, lors d'une restauration d'une table, que les index soient activées.
Je peux vous assurer que cela va prendre un temps bien plus long puisque à chaque insertion, il y aura réorganisation de la table.
Surtout si les lignes ne se présentent pas dans l'ordre de l'index cluster (celui de la primary key, puisque MySql ne fait pas la distinction).
Le mieux est de trier les lignes avant de les charger, et d'activer les index quand la table est totalement chargée.
@+
Reste alors le besoin de mettre à jour les index, et de les rééquilibrer de temps en temps au fur et à mesure de leur écriture... ça me semble clairement moins gênant !
Le pire dans tout ça, c'est : que se passe-t-il si on crée la clé primaire (ou le premier index unique) après coup ?
D'après la doc de MySQL, l'index cluster (donc l'organisation physique des données sur le disque) est obligatoirement la clé primaire si présente, le premier index unique créé sinon, et enfin une clé primaire "technique" générée à partir d'une colonne "technique" généré automatiquement par MySQL (donc une augmentation inutile de données à stocker). Que se passe-t-il alors si on crée la clé primaire à postériori ? 9 chances sur 10 que ça se traduire par une réorganisation compète des données sur le disque, ce qui sera infiniment plus lent que de rééquilibrer un index... (d'autant qu'à ce moment tous les index doivent être mis à jour, puisque tous référencent la clé primaire... qu'on vient de créer).
Ce serait très surprenant que MySQL ne fasse pas ça, sinon il laisserait le choix de l'index cluster, puisque ça revient au même.
Salut StringBuilder.
Je fais cette constatation sous MySql : si les index sont activés durant la restauration de la table, cela prendra beaucoup plus de temps que de désactiver les index durant la restauration de la table, puis de les réactiver ensuite.
@+
Répondre avec citation
Partager