Champ en MEDIUMTEXT à la place de VARCHAR : moins rapide? - SQL/NoSQL - Programmation
Marsh Posté le 18-10-2010 à 13:25:08
En theorie tant que tu fais pas de query qui te retourne ton champ TEXT ca devrai aller un peu plus vite (en fonction de quel index est utilisé) vu que la taille de la table diminue.
Par contre ca plombe les perfs quand tu fais bcp de queries avec le champ Text car il faut chaque fois aller le chercher (2 IOs au lieu de 1).
Tout depend de ce que tu fais en gros.
Ca c'est la theorie pour SQL Server, a voir si ca s'applique dans MySQL
Marsh Posté le 18-10-2010 à 15:28:13
Moi, j'ai surtout beaucoup de requêtes de listages de tickets avec leur statut mais pas de recherche ou récupération des champs VARCHAR de l'historique. En fait, je l'ai juste quand j'affiche un ticket (normal) et dans qq extract de BD qui tournent 1 à 2 fois par semaine. Donc, de ce que tu me dis, j'en déduit que mes listage de demandes vont aller un peu plus vite et que l'affichage de mes tickets + extracts vont prendre un poil plus de temps à cause des 2 IO par ligne d'historique. J'ai bon?
En plus, mon test sur les listage en ayant mis un MEDIUMTEXT semble confirmer qu'effectivement, ça prend un peu moins de temps. Faut que je vérifie pour l'affichage d'un ticket (mais la diff de perf doit être tellement minime...)
Marsh Posté le 19-10-2010 à 07:51:55
Oui c'est bien ca.
Ca devrai donc etre tout bon pour toi.
Marsh Posté le 18-10-2010 à 11:24:59
Bonjour,
Je me pose une petite question pour soft Astres (cf ma signature). J'ai 2 tables (MyIsam sous Mysql) : l'une contenant les tickets et l'autre contenant les différentes entrées de leur historique respectif (changements d'états et petites infos tracées pour mémoire sur l'avancement), donc une relation 1-N. Le champ permettant de tracer des infos pour mémoire est actuellement un VARCHAR(255) mais il faudrait, aujourd'hui, qu'il puisse contenir plus d'infos (un bloc texte). Je pense donc le passer en MEDIUMTEXT. Mais je sais que les champs de type BLOB ou TEXT sont stockés différemment des CHAR ou VARCHAR (ces derniers sont stockés dans la table alors que les premiers sont stockés dans un fichier hors de la table il me semble). Je me demandais donc du coup, si j'allais pas plomber les perfs de mon SGBD? J'ai fait un test sur une base de pré-prod relativement représentative de ce que j'ai en prod et j'ai l'impression que pour le coup, ça les auraient presque amélioré les perfs Il est vrai que tous les autres champs de la table de l'historique (excepté celui en VARCHAR) sont des champs à taille fixe... Je me demande si ça vient de là...
Merci par avance pour votre aide
---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta