MySQL varchar(2000) vs texte?

J'ai besoin de stocker en moyenne un paragraphe de texte, qui serait d'environ ~800 caractères dans la base de données. Dans certains cas rares, il peut aller jusqu'à 2000-2500~ caractères. J'ai lu le manuel et je sais qu'il ya beaucoup de ces questions déjà, mais j'ai lu plus de 10+ questions sur stackoverflow et je trouve toujours un peu difficile à comprendre si je dois simplement utiliser du texte ou quelque chose comme varchar(2000). La moitié semble dire l'utilisation de type varchar, tandis que l'autre demi-dire du texte. Certaines personnes disent toujours utiliser le texte si vous avez plus de 255 caractères (oui, c'était après 5.0.3 qui a permis varchar jusqu'à 65k). Mais ensuite j'ai pensé à moi-même si je devais utiliser du texte chaque fois que les personnages ont plus de 255, alors pourquoi mysql peine l'augmentation de la taille du tout si cela a toujours été la meilleure option?

Ils ont une taille variable de stockage que j'ai lu, donc y aurait-il pas de différence dans ma situation? Personnellement, j'ai été penché vers varchar(2000) puis j'ai lu que varchar stocke les données en direct tandis que le texte ne le fait pas. Est-ce à dire que, si j'ai constamment la sélection de cette colonne, le stockage de données varchar serait mieux, et à l'inverse si j'ai rarement la sélection de cette colonne, puis en utilisant le texte serait mieux? Si cela est vrai, je pense que je voudrais maintenant, choisissez la colonne de texte que je ne vais pas être la sélection de cette colonne de nombreuses fois j'ai l'exécution d'une requête sur la table. Si c'est important, cette table est également fréquemment rejoint aussi bien (mais qui ne sera pas le choix de la colonne), serait-ce aussi les avantages de l'utilisation de texte?

Sont mes hypothèses de corriger ce que je doit aller avec le texte dans ce cas?

  • Penser en termes de l'utilisation de la mémoire. Les champs VARCHAR sont une partie de la ligne, où les colonnes de TEXTE sont juste fait sur le disque par une adresse dans la ligne. Votre décision aura une incidence sur la mise en cache de requêtes (combien de jeux de résultats peuvent tenir dans ce mémoire), la table de cache (le nombre de tables qui peuvent tenir dans la mémoire), le nombre de lignes tenir dans diverses par requête tampons, etc.
InformationsquelleAutor Joker | 2011-02-19
  1. 16

    Lorsqu'une table est de type TEXT ou BLOB colonnes, le tableau ne peut pas être stockée dans la mémoire. Cela signifie que chaque requête, qui ne frappe pas de cache) a accès au système de fichiers - qui est un ordre de grandeur plus lent que la mémoire.

    Par conséquent, vous devez conserver cette colonne de TEXTE dans un autre tableau qui est accessible uniquement lorsque vous en avez besoin. De cette façon, la table d'origine peuvent être stockées en mémoire et sera beaucoup plus rapide.

    Pense que de séparer les données dans un "mémoire de la table" et une "table de fichiers". La raison pour cela est pour éviter l'accès du système de fichiers, sauf lorsque cela s'avère nécessaire (c'est à dire que quand vous avez besoin le texte).

    Vous n'avez pas gagner quoi que ce soit par stockage du texte dans plusieurs tables. Vous avez toujours accès au système de fichiers.

    Désolé je voulais dire par exemple, un forum de script, dans la table posts qu'ils pourraient être >le stockage de 20 colonnes de données post, ils ont également stocker le message comme un champ de texte dans l' >même table. De sorte que post-colonne doivent être séparées?

    Oui.

    Ça fait bizarre d'avoir une table appelée post, mais le message n'est pas stocké là, peut - >dans une autre table appelée "actual_post" pas sûr lol.

    Vous pouvez essayer (poteaux, post_text) ou (post_details, poteaux) ou quelque chose comme ça.

    J'ai une table tags qui a juste trois champs, tag_id, tag, et la description. De sorte que >description colonne doit également être séparées? J'ai donc besoin d'une table tags et a >tags_description table pour stocker les 3 colonnes?

    Si la description est une colonne de TEXTE et d'exécuter des requêtes sur cette table qui n'a pas besoin de description, il serait certainement préférable.

    • Désolé, que voulez-vous dire quand vous dites, "les tables à l'aide de TEXTE ne peut pas être en mémoire, mais exige de file I/o". Donc, est-ce à dire, même si je voulais utiliser du texte dans ce cas, je ne pouvais pas (si je l'ai gardé dans la même table).
    • Merci pour l'expliquer en détail. Bien que si c'est aussi grave que ça, n'est-ce pas ce à dire que toutes les colonnes de texte doivent être stockées dans une table séparée depuis même une colonne de moins de 2000 caractères doit être séparé des autres? Avez-vous des exemples de cas où une colonne de texte doivent être conservés dans le même tableau de données pertinentes?
    • J'ai mis à jour ma réponse à la commande à l'adresse de votre question.
    • Désolé je voulais dire par exemple, un forum de script, dans la table posts ils pourraient être de stockage de 20 colonnes de données post, ils ont également stocker le message comme un champ de texte dans la même table. De sorte que post-colonne doivent être séparées? Ça fait bizarre d'avoir une table appelée post, mais le message n'est pas stocké là, peut-être dans une autre table appelée "actual_post" pas sûr lol. J'ai une table tags qui a juste trois champs, tag_id, tag, et la description. De sorte que la colonne description devrait également être séparées? J'ai donc besoin d'une table tags et un tags_description table pour stocker les 3 colonnes?
    • J'ai mis à jour ma réponse à la commande à l'adresse de votre question.
    • Pourquoi les gens sont rarement faire cela, alors? Même dans beaucoup d'applications commerciales qui tiennent beaucoup sur les performances ne semblent pas faire cela. Le plus drôle, c'est que j'ai l'habitude de le faire, mais plus tard changé pour l'ajout à la table principale. Maintenant, je dois revenir à ce que j'ai fait avant... c'Est aussi quelque chose que vous devriez faire dès le début, ou de conserver les données dans le même tableau, et seulement si vous voyez des problèmes, alors essayez de les séparant? N'aurais-je pas juste être mieux d'utiliser varchar(2000) dans la table principale à la place?
    • Je suppose que cela semble juste bizarre pour moi, imaginez si vous aviez 50 tables, et 30 de ces tables besoin de descriptions, maintenant vous avez besoin de plus de 30 tables qui ont juste 1 colonne à tenir chaque description.
    • J'apprécierais si vous avez accepté l'une des réponses 😀
    • Je vais voir si il y avait d'autres opinions. Mais n'aurais-je pas juste être mieux d'utiliser varchar(2000) dans la table principale au lieu de tous les tracas? Cela signifie également que lorsque je mettre à jour ou supprimer des enregistrements j'ai aussi besoin de faire plusieurs tables. Je pensais aussi que l'utilisation du texte est également préférable si vous n'avez pas de plan pour le sélectionner tout le temps, mais que vous dit le contraire. J'ai aussi remarqué que vous avez dit pour la non mise en cache des requêtes, il serait beaucoup plus lent, mais, en général, la plupart des requêtes deviendra le cache droit?
    • Vous pouvez bien sûr utiliser VARCHAR(2000) et de la chance, plus tard, si la performance suce. Toutefois, si vous SÉLECTIONNEZ à partir de la table, mais n'ont pas besoin du paragraphe de texte, vous feriez mieux de les stocker dans une table séparée.
    • Quand vous avez dit que, "Lorsqu'une table est de type TEXT ou BLOB colonnes, le tableau ne peut pas être stockée dans la mémoire" je ne pense pas que c'est vrai. Je viens de lire à partir de mysql.com que uniquement si vous sélectionnez la valeur que vous obtenez une pénalité sur les performances, car il utilise le disque. C'est pourquoi ils disent d'éviter les SELECT *. Donc, si vos requêtes ne fait pas de sélectionner la colonne de texte, je ne pense pas que cela va être aussi mauvais que vous le dites. C'est pourquoi vous me trompez, car comme je l'ai dit dans mon premier post, j'ai pensé que si vous ne sélectionnez pas la valeur comme beaucoup de texte est en fait mieux que varchar.
    • Ma compréhension est que les colonnes de TEXTE sont stockées séparément de toute façon, afin de les stocker dans une table distincte est inutile. En fait, il y a une question à ce sujet ici et les gens répondre à cette faveur: stackoverflow.com/questions/1849269/... - quelles sont vos pensées sur cette question? Avez-vous toujours à ce que vous avez dit ici? Essayer de travailler sur ce qui est bon, merci!

    InformationsquelleAutor
  2. 1

    Je pense que vous le résume bien. Une autre chose que vous pourriez envisager est juste déplacer le "texte" à une autre table... et rejoignez retour à la fiche. De cette manière, chaque fois que vous êtes en fait en utilisant la table de maître, les données supplémentaires de l'endroit où le "texte" est n'est même pas prendre l'espace dans la fiche. Quand vous en avez besoin, vous pouvez vous joindre à la table. De cette façon, vous pouvez l'enregistrer dans un varchar juste au cas où vous voulez faire quelque chose comme " où le texte que... "

    • J'ai utilisé de faire de cette façon, mais on m'a dit autrement, à moins que je faisais beaucoup de requêtes par seconde, il est préférable de le stocker dans le même tableau. J'ai aussi pensé à 2000 caractères de données n'est pas pour le mettre dans un tableau distinct. Un autre cas lorsque certains disent une chose et une autre dit autre chose. 😛 je devrais Peut-être garder la colonne dans la table pour l'instant et si jamais j'ai des problèmes de déconnexion?
    • Les réponses à cette question semblent suggérer que nous ne devrions pas être stocker dans une autre table. Les pensées de n'importe qui? @Joker? Juste essayer d'obtenir une réponse solide sur ce. Des acclamations.
    InformationsquelleAutor John Sobolewski