Inconvénients de MySQL

Points faibles et pièges

• Réglages permissifs sur certains serveurs. Sans le mode strict (strict mode), MySQL et MariaDB tronquent sans rien dire les textes trop longs ou enregistrent une valeur de remplacement à la place d’une valeur invalide, et n’émettent qu’un avertissement. Dans les versions actuelles, le mode strict est activé par défaut, mais les hébergeurs le désactivent souvent. La requête SELECT @@sql_mode; montre le mode utilisé par le serveur – en mode strict, elle contient STRICT_TRANS_TABLES ou STRICT_ALL_TABLES.
• Différences entre MySQL et MariaDB. MariaDB est née comme une branche dérivée (fork) de MySQL et les deux bases s’éloignent de plus en plus l’une de l’autre. Le SQL courant fonctionne de la même façon dans les deux, mais elles diffèrent par leurs réglages par défaut (par exemple le mode ONLY_FULL_GROUP_BY), certaines fonctions, le type de données JSON et le comportement de l’optimiseur. Lors du passage de l’une à l’autre, il faut tester l’application.
• Les changements de structure ne s’annulent pas. Les commandes qui modifient la structure des tables (CREATE, ALTER, DROP) valident automatiquement la transaction en cours et ne peuvent pas être annulées par ROLLBACK. Il est donc impossible de modifier la structure et les données en une seule opération, annulée entièrement en cas d’erreur. PostgreSQL sait modifier la structure à l’intérieur d’une transaction.
• Moins de fonctions avancées que PostgreSQL. PostgreSQL offre des types de données plus riches (tableaux, plages de valeurs, types personnalisés), davantage de possibilités d’indexation des données JSON et des extensions comme PostGIS pour les données géographiques. MySQL n’applique les contraintes CHECK que depuis la version 8.0.16 – les versions plus anciennes les acceptaient, mais les ignoraient.
• Recherche plein texte et formes des mots. L’index FULLTEXT intégré ne connaît pas les autres formes d’un mot (la recherche du mot cheval ne trouve pas chevaux, et manger ne trouve pas mangeons) et ignore les mots très courts. Pour une bonne recherche dans les textes, on utilise des outils de recherche séparés comme Elasticsearch.
• Répartir les écritures sur plusieurs serveurs. Un seul serveur suffit même pour un site très fréquenté. La réplication classique répartit toutefois surtout les lectures – des solutions avec plusieurs serveurs qui acceptent les écritures (par exemple Galera Cluster pour MariaDB) existent, mais leur maintenance demande beaucoup plus de travail.
• Propriétaire et licence. MySQL appartient à Oracle, qui propose à côté de l’édition gratuite Community (licence GPL) une édition payante Enterprise avec des outils supplémentaires. Une partie de la communauté est donc passée à MariaDB, fondée par l’un des auteurs d’origine de MySQL (état en septembre 2026).

Ce qui n’est plus vrai

D’anciens comparatifs affirment que MySQL ne gère pas les transactions, les clés étrangères, les vues, les procédures stockées ni les déclencheurs et qu’il ne suffit pas pour des applications exigeantes. Cela concernait de très anciennes versions et l’ancien type de tables MyISAM. Les versions actuelles avec le type InnoDB par défaut savent faire tout cela, MySQL 8.0 et MariaDB 10.2 ont par exemple ajouté les fonctions de fenêtrage et les requêtes avec la clause WITH, et des sites très fréquentés fonctionnent eux aussi sur MySQL.

Quand choisir une autre base de données

• PostgreSQL – modèles de données plus complexes, requêtes analytiques, données géographiques et respect strict de la norme SQL.
• SQLite – petites applications, prototypes et outils sans serveur de base de données. Toute la base de données tient dans un seul fichier.
• MySQL ou MariaDB restent un bon choix pour les sites courants, les boutiques en ligne et les systèmes de gestion de contenu. Ils sont disponibles chez presque tous les hébergeurs et la plupart des applications web en PHP en ont besoin.

Articles connexes :
Types de données des colonnes
Regroupement et totaux (GROUP BY)
Insérer, modifier et supprimer des données