J'utilise deux serveurs MySQL (production et test). J'exécute la même requête sur les deux via MySQL Workbench, mais les résultats ne sont pas dans le même ordre. Quelle en est la raison?
La requête:
select table_name, table_collation from information_schema.tables where table_schema = 'orchestration' order by table_name asc`
3 Réponses :
Est-il possible que votre classement soit différent localement par rapport au serveur? Par exemple. vous avez lancé local avec mysqld --character-set-server = utf8mb4 , ou quelque chose de tout à fait différent du serveur de production?
De plus, le système d'exploitation sous-jacent peut se comporter différemment. Je ne me souviens pas avoir vu un jeu de caractères spécifique qui triait différemment «_» et «s», mais je suppose que c'est possible.
J'ai ajouté une capture d'écran à mon message d'origine; est-ce que cela aide?
La réponse de Bill Karin ci-dessus est plus ciblée; différentes versions vous donneront un monde de maux de tête (et pas seulement un problème MySQL!). Pouvez-vous exporter le DB de test et le charger dans la même version en test?
On dirait que c'est la direction dans laquelle je vais devoir aller!
la version de test est la 8.0.11; la production est de 5,6,33
MySQL 8.0 change complètement l'implémentation interne de INFORMATION_SCHEMA. Voir https://mysqlserverteam.com/mysql-8-0-improvements- to-information_schema / pour l'annonce.
Je vois aussi que vous utilisez un classement utf8 en test, mais utf8mb4 en production, et encore une fois, en utilisant différentes versions. MySQL a également apporté des corrections à leurs classements entre les versions. Parfois, ils avaient un bogue avec leur implémentation plus ancienne, et parfois la spécification du classement est mise à jour par un comité de normalisation, et MySQL change pour maintenir la compatibilité avec le standard.
De nombreux logiciels apportent des modifications entre les versions majeures, et vous ne devez pas vous attendre à une compatibilité parfaite entre eux.
Vous devez vous assurer que vous développez, testez et déployez en production en utilisant la même version de tous les packages logiciels de votre pile technologique. Les bases de données, les langages, les frameworks, les serveurs Web, les serveurs de cache, les proxys, les équilibreurs de charge, les files d'attente de messages, les bibliothèques, etc. peuvent tous introduire des changements subtils même s'ils ne sont pas documentés.
Vous risquez d'être surpris par des incompatibilités et des bugs si vous testez sur une version mais déployez en production sur une version différente de la pile technologique. En effet, vos tests ne garantissent pas que votre code fonctionnera en production!
Salut Bill. Je veux creuser plus profondément, mais j'ai heurté un barrage routier. SHOW CREATE TABLE information_schema.TABLES s'avère être un VIEW , mais la sortie est tronquée. Où puis-je trouver les schémas des nouvelles tables DD 8.0? (Et pourquoi le SHOW est-il tronqué?)
J'ai essayé sur une instance sandbox de 8.0.14, et elle ne semble pas tronquée. J'utilise SHOW CREATE TABLE ou SHOW CREATE VIEW et je le vois comme 4205 caractères. Les "vues" intéressantes dans information_schema n'apparaissent pas elles-mêmes dans information_schema.views .
J'ai utilisé 8.0.15 dans le docker. La sortie n'est pas allée jusqu'à donner le FROM ou JOIN pour me dire où se trouvent les tables sous-jacentes. Pouvez-vous me dire ce qu'ils sont? Et est-il possible de faire SHOW sur eux?
Les tables sous-jacentes sont mysql.tables , mysql.schemata , mysql.catalogs , mysql.collations , mysql.tablespaces , mysql.table_stats . Ce sont des objets de dictionnaire de données internes, et ils ne sont pas affichables: ERREUR 3554 (HY000): L'accès à la table de dictionnaire de données 'mysql.tables' est rejeté. Voici une explication: lefred.be/content/…
Merci, mais pouah. Je poursuivrai cela quand j'aurai une semaine libre. Même si je pouvais voir les tables «cachées», cela pourrait ne pas expliquer pourquoi _ semble être assemblé différemment.
select table_name, table_collation
from information_schema.tables
order by table_name COLLATE utf8_general_ci;
Notes:
S < _ < s -- So if someone is doing UPPER() or LOWER(), the ordering changes.
utf8_bin and utf8_general_ci give different answers; perhaps the underlying DD table changed?
(Alas, I was not able to get to the bottom of the issue.)
Les instances de production et de test de MySQL exécutent-elles la même version?
Bill Karwin, la version de test est 8.0.11; la production est de 5,6,33