Discussion :

[fanfouer]

Bonjour,

Je me pose une question sur les index de type UNIQUE.
Ma servant habituellement à éviter tout doublon dans certaines de mes tables, la longueur de la clé appliquée à certains champs attire mon attention.

Imaginons une table (codage en UTF8_général_ci) possédant un champ de type VARCHAR (500). Même si la longueur n'importe normalement plus dans VARCHAR, je prévois d'y stocker des chaines de longueur comprises entre 450 et 500 caractères (soit 1000 o max en UTF8).
Il parait logique d'appliquer la longueur de clé correspondant à ce champ de 500 caractères.

SQL bloque une 1ere fois et pour cause : longueur maximale de 767 o soit 383 caractères UTF8.
Abaissons donc la longueur de la clé à 380 caractères.

Ca ne correspond plus à mon cas puisque mes chaines vont faire entre 450 et 500 caractères.

J'ai fais le test et m'aperçoit qu'au moment d'utiliser INSERT avec des chaines proches (différences sur les derniers caractères), MySQL affirme trouver un doublon alors qu'il n'en est rien.

Quelle est la logique derrière cette limitation à 767 octets des longueur de clé? Peut-on passer outre?

Merci pour vos réponses.

[ericd69]

c'est normal, il y a une limite d'indexation pour les textes (hors fulltext on s'entend bien)

il y a un paramètre dans mysql qui définit le réglage de cette limite (en général de l'ordre de 1024o)

donc forcément si les n premiers octets (selon le réglage) sont les mêmes il considère que c'est un doublon...

et c'est fait pour une question de taille et performance... les index texte c'est le mal (niveau performance) !!

tu devrais lire la doc sur les variables serveur pour max_sort_length et max_length_for_sort_data

[SQLpro]

1) MySQL est le plus limité des SGBDR en matière d'indexation, là ou la limite est de 800 à 1000 caractères dans un index MySQL ne dépasse effectivement pas les 266 octets (soit 800 divisé par 3 du fait de l'encodage o combien débile de l'YTF8)
2) à partir de ce moment, MySQL tronque les données, mais sans le dire (une maladie générale de MySQL est de faire des erreurs silencieuse!!!) ni à quel offset.... et trouve donc des doublons

A lire sur les méfaits de MyySQL : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

[fanfouer]

Bonjour,

Merci à vous deux pour vos réponses.

Ericd69, en effet c'était bien cela, le problème de base a été solutionné.

SQLPro, ce constat n'est pas négligeable.
Cependant je suis vraiment perplexe par rapport à ça. Il ne faut pas confondre manque réel de fonctionnalités par rapport aux concurrents et manque fonctionnel par rapport au besoin de l'utilisateur.
MySQL répond à +90% de mes besoins actuellement, comme beaucoup d'autres certainement.
Peut-être que cela vient-il d'un manque d'ouverture et que l'on a tendance à concevoir les couches 2 en fonction de ce que MySQL ne fait pas pour pouvoir continuer à l'utiliser (ce qui n'est pas très bien objectivement).
Peut-être aussi que certaines choses n'ont pas été implémentées pour conserver une efficacité sur les trucs basiques.

Je prévoyais de toute façon de migrer une partie de ma base, la plus chargée en relations et en choses exotiques, vers PostgreSQL.
Non pas pour les manques de MySQL mais parce que Pg propose un bon moteur spatial.

[SQLpro]

Entre nous le SIG de MySQL c'est la pire merde que j'ai vu dans ma vie.Allez voir le bug que j'avais mentionné sur le SIG qui voyait un point dans un trinagle alors qu'il était à l'extérieur !!!! ici et vous m'en direz des nouvelles.

C'est plus qu'une honte !

A +