Planifier sa migration MySQL
octobre 21, 2020
Since 8.0.16, MySQL Server supports a –validate-config option that enables the startup configuration to be checked for problems without running the server in normal operational mode.
–validate-config can be used any time, but is particularly useful after an upgrade, to check whether any options previously used with the older server are considered by the upgraded server to be deprecated or obsolete.
Since MySQL 5.7 one can put indexes on expressions, aka functional indexes, using generated columns. Basically you first need to use the generated column to define the functional expression, then indexed this column.
Quite useful when dealing with JSON functions, you can find an example here and the documentation there.
Starting with MySQL 8.0.13 we have now an easiest way to create functional indexes (or functional key parts as mentioned in the documentation) \o/
Let’s see how with a quick practical example.
Lorsque l’on démarre un nouveau projet, il est en général conseillé de partir sur la version la plus récente de MySQL, histoire de profiter des toutes dernières fonctionnalités mais aussi (surtout ?) d’être certain d’être à jour au niveau des patchs de sécurité.
Cet article centralise les différentes URLs pour télécharger la base de données Open Source la plus populaire au monde.
j’ai régulièrement l’opportunité de rencontrer les utilisateurs des produits MySQL, et je suis toujours un peu surpris de voir des applications critiques qui tournent sur des versions pas vraiment récente (pour employer un euphémisme) 🙂
La bonne nouvelle est que manifestement les anciennes versions de MySQL sont suffisamment stables et performantes pour faire tourner du business moderne. Cependant, et ce même si je comprend bien qu’il est parfois pertinent de figer toutes les couches d’une architecture, il est souvent dommage de ne pas profiter des dernières améliorations d’un point de vue, performance, stabilité, sécurité et bien entendu des nouvelles fonctionnalités de la dernière GA
Un comportement bizarre m’a été remontée par un collègue.
J’ai une table qui contient des IDs (pas la clé primaire):
SELECT DISTINCT ID FROM Connection WHERE…\G
*************************** 1. row ***************************
ID: 12345678
J’utilise la fonction CONCAT pour concaténer une chaîne de caractères et les IDs de la table:
Le problème du jour, une table qui contient (entre autre) 2 colonnes de type entier non signé ( NombPart & NombInscr).
Une requête, qui fait la soustraction entre NombInscr et NombPart, pour remplir une autre table à la volée :
CREATE TABLE …
SELECT … NombInscr – NombPart as NombAbs …
FROM … ;
Et là, c’est le drame…
ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in ‘(NombInscr – NombPart)’
Lors d’une discussion à la cafèt, la question suivante fut posée : « Faire un ALTER TABLE avec plusieurs instructions est il plus rapide qu’un ALTER TABLE par instruction » ?
Les 2 protagonistes n’étant pas d’accord entre eux, c’est tout naturellement que je fus invité à donner mon avis.
La réponse me semble assez intuitive, mais comme des chiffres valent mieux qu’un longs discours…
MySQL est connu pour ne pas être très performant avec les sous-requêtes. Ce n’est pas faux, et d’ailleurs c’est encore le cas avec MySQL 5.5. Le contournement consiste en général à réécrire la requête, certaines sous-requêtes pouvant être aisément réécrite en jointure.
C’est le cas de
SELECT a FROM T1 WHERE col IN (SELECT col FROM T2…) qui se transforme en
SELECT distinct a FROM T1 INNER JOIN T2 ON TI.col=T2.col WHERE …