Le logiciel MySQL (TM) est un serveur de base de données SQL
très rapide, multi-threadé, multi-utilisateur et robuste.
Le serveur MySQL est destiné aux missions stratégiques et aux systèmes
de production à forte charge, ainsi qu'à l'intégration dans des logiciels
déployés à grande échelle.
MySQL est une marque déposée de MySQL AB.
Le logiciel MySQL dispose de deux licenses. Les utilisateurs peuvent
choisir entre utiliser MySQL comme un logiciel Open Source/Logiciel libre,
sous les termes de la licence GNU General Public License
(http://www.gnu.org/licenses/) ou bien, ils peuvent acheter une
licence commerciale auprès de MySQL AB.
See section 1.4 Support MySQL et licences.
Le site web de MySQL (http://www.mysql.com/) fournit les dernières
informations sur le serveur MySQL.
La liste suivante décrit les sections particulières de ce manuel :
serveur de base de données MySQL,
voyez section 1.3 Qui est MySQL AB ?.
serveur de base de données MySQL,
voyez section 1.2.2 Les fonctionnalités principales de MySQL.
serveur de base de données MySQL sur
de nouvelles architectures ou systèmes d'exploitation, voyez section D Port vers d'autres systèmes.
serveur de base de données MySQL,
voyez section 3 Tutoriels d'introduction.
SQL et des tests de performances, voyez le dossier
de tests (`sql-bench' de la distribution.
Important:
Les rapports d'erreurs (aussi appelés bogues), ainsi que les questions et commentaires, doivent être envoyés à la liste de diffusion mysql@lists.mysql.com. See section 1.7.1.3 Comment rapporter un bogue ou un problème.
Le script mysqlbug doit être utilisé pour générer le rapport de bogues.
Pour les distributions sources, le script mysqlbug est accessible dans le
dossier `scripts'. Pour les distributions binaires, mysqlbug est
installé dans le dossier `bin' (`/usr/bin' pour le package RPM du
serveur MySQL).
Si vous avez trouvé un problème de sécurité critique
dans le code du serveur MySQL, vous devez envoyez un email à
security@mysql.com.
Ceci est le manuel de référence de MySQL; il documente MySQL
jusqu'à la version 5.0.0-alpha. Les évolutions fonctionnelles
sont toujours indiquées avec une référence à la version d'évolution,
de manière à ce que ce manuel soit toujours valable, même si vous utilisez
une ancienne version de MySQL.
Etant un manuel de référence, il ne fournit aucune description générale
sur le langage SQL ou les concepts de bases de données relationnelles.
Comme le logiciel de base de données MySQL est en développement constant,
ce manuel es mis à jour fréquemment.
La version la plus récente est disponibles à
http://www.mysql.com/documentation/ en différents formats, incluant
HTML, PDF et Windows HLP.
L'original du document est un fichier au format Texinfo.
La version HTML est produite automatiquement avec une version modifiée de
texi2html.
La version en texte plein et version Info sont produites par makeinfo.
La version PostScript est produite avec texi2dvi et dvips.
La version PDF est produite avec pdftex.
Si vous avez du mal à trouver des informations dans ce manuel, vous pouvez essayer notre version avec moteur de recherche, sur notre site web : http://www.mysql.com/doc/.
Si vous avez des suggestions concernant des ajouts ou des corrections à ce manuel, vous pouvez les envoyez à l'équipe de documentation à docs@mysql.com.
Ce manuel a été écrit initialement par David Axmark et Michael (Monty) Widenius. Il est actuellement entretenu par Michael (Monty) Widenius, Arjen Lentz et Paul DuBois. Pour les autres contributeurs, voyez les section B Crédits.
La traduction de ce manuel a été faite sous la direction de Damien Seguy, et organisée par Mehdi Achour. David Manusset, Guillaume Plessis, Patrick Haond, Sylvain Maugiron et Yannick Torres ont contribué largement à cette traduction et son entretien.
Le copyright (2002) de ce manuel est la propriété de la société suédoise
MySQL AB. See section 1.4.2 Copyrights et licences utilisées par MySQL.
Ce manuel utilise certaines conventions typographiques :
constant
mysqladmin fonctionne, exécutez-le
avec l'option --help.''
Lorsque les commandes qui sont affichées sont destinées à être exécutées
par un programme particulier, le nom du programme est indiqué dans l'invite
de la commande. Par exemple, shell> indique une commande que vous exécutez
depuis votre console shell, et mysql> indique une commande que vous exécutez
depuis le client mysql :
shell> tapez une commande shell ici mysql> tapez une requête SQL ici
Les commandes shell sont affichées en utilisant la syntaxe du Bourne. Si vous utilisez
le style csh-shell, vous aurez peut être a adapter légèrement les commandes.
Par exemple, la syntaxe de modification d'une variable et d'exécution d'une commande
ressemble à ceci en Bourne shell :
shell> NOMVAR=valeur une_commande
En csh, vous auriez a exécuter la commande suivante :
shell> setenv NOMVAR valeur shell> une_commande
Souvent, les noms de bases de données, tables ou colonnes doivent être
remplacés dans les commandes. Pour indiquer qu'une telle substitution
est nécessaire, ce manuel utilise les noms de nom_de_base,
nom_de_table et nom_colonne. Par exemple, vous pourriez avoir une
requête comme ceci :
mysql> SELECT nom_colonne FROM nom_de_base.nom_de_table;
Cela signifie que si vous devez saisir une requête semblable, vous devriez utiliser votre propre nom de colonne, table et base de données, ce qui pourrait se traduire par ceci :
mysql> SELECT author_name FROM biblio_db.author_list;
Les mot réservés SQL ne sont pas sensibles à la casse, et peuvent être écrits en majuscules ou minuscules. Ce manuel utilise les majuscules.
Dans les illustrations de syntaxe, les crochets (`[' et `]') sont
utilisés pour indiquer des clauses ou mots optionnels. Par exemple, dans la requête
suivante, IF EXISTS est optionnel :
DROP TABLE [IF EXISTS] nom_de_table
Lorsqu'un élément de syntaxe est constitué d'un certain nombre d'alternatives, les alternatives sont séparées par des barres verticales (`|'). Lorsqu'un membre d'un tel jeu de possibilités peut être choisi, les alternatives sont listées entre crochets (`[' et `]'):
TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)
Lorsqu'un élément d'un jeu de possibilités doit être choisi, les alternatives sont placées entre accolades (`{' et `}'):
{DESCRIBE | DESC} nom_de_table {nom_colonne | wild}
MySQL, le plus populaire des serveurs de bases de données SQL Open Source,
est développé, distribué et supporté par MySQL AB. MySQL AB est une
société commerciale, fondée par les développeurs de MySQL, qui développent leur
activité en fournissant des services autour de MySQL.
section 1.3 Qui est MySQL AB ?
Le site web de MySQL (http://www.mysql.com/)
fournit les toutes dernières actualités sur le logiciel MySQL
et sur la société MySQL AB.
MySQL est un système de gestion de bases de données.
MySQL. Comme les ordinateurs sont très bons à manipuler de grandes
quantités de données, le système de gestion de bases de données joue un rôle
central en informatique, aussi bien en tant qu'application à part entière,
qu'intégré dans d'autres logiciels.
MySQL est un serveur de bases de données relationnel.
SQL dans
``MySQL'' signifie ``Structured Query Language'' : le langage
standard pour les traitements de bases de données.
MySQL est Open Source.
Open Source (Standard Ouvert) signifie qu'il est possible à chacun
d'utiliser et de modifier le logiciel. Tout le monde peut télécharger
MySQL sur Internet, et l'utiliser sans payer aucun droit. Toute personne
en ayant la volonté peut étudier et modifier le code source pour l'adapter à
ses besoins propres. Le logiciel MySQL utilise la licence
GPL (GNU General Public License),
http://www.gnu.org/licenses/, pour définir ce que vous pouvez et ne
pouvez pas faire avec ce logiciel, dans différentes situations. Si vous ne
vous sentez pas confortable avec la licence GPL ou bien que vous
devez intégrer MySQL dans une application commerciale, vous pouvez acheter
une licence commercial auprès de MySQL AB.
See section 1.4.3 Licences MySQL.
MySQL?
serveur de bases de données MySQL est très rapide, fiable
et facile à utiliser. Si c'est ce que vous recherchez, vous devriez faire
un essai. Le serveur de bases de données MySQL dispose aussi de
fonctionnalités pratiques, développées en coopération avec nos utilisateurs.
Vous pouvez trouver une comparaison des performances du
serveur MySQL avec d'autres systèmes de bases de données dans
nos pages de tests de performances.
See section 5.1.4 La suite de tests MySQL.
Le serveur MySQL a été développé à l'origine pour gérer de grandes bases
de données plus rapidement que les solutions existantes, et a été utilisé
avec succès dans des environnements de production très contraints et
très exigeants, depuis plusieurs années. Bien que toujours en développement,
le Le serveur MySQL offre des fonctions nombreuses et puissantes. Ses
possibilités de connexions, sa rapidité et sa sécurité font du serveur MySQL
une serveur hautement adapté à Internet.
serveur MySQL.
logiciel de bases de données MySQL est un système client/serveur,
constitué d'un serveur SQL multi-threadé qui supporte différents
systèmes de stockage, plusieurs logiciels clients et librairies, outils
d'administration, ainsi que de nombreuses interfaces de programmation
(des API).
Nous fournissons aussi le serveur MySQL sous la forme d'une librairie multi-threadé
que vous pouvez inclure dans vos applications, pour obtenir un produit plus
compact, plus rapide et plus facile à gérer.
MySQL.
serveur de base de données MySQL.
La prononciation officielle de MySQL est ``My Ess Que Ell'' (en anglais),
ce qui donne ``Maille Esse Cu Elle'' en phonétique française. Evitez d'utiliser
la prononciation ``my sequel'', mais nous ne nous formaliserons pas que vous utilisiez
``my sequel'' ou une autre prononciation adaptée.
Nous avons débuté avec l'intention d'utiliser mSQL pour se connecter
à nos tables en utilisant nos propres routines bas niveau ISAM. Cependant,
après quelques tests, nous sommes arrivés à la conclusion que
mSQL n'était pas assez rapide et flexible pour nos besoins. Cela nous a
conduit à créer une nouvelle interface SQL pour notre base de données, mais
en gardant la même API que mSQL. Cette API a été choisie pour la facilité
de port des programmes de tiers.
Les liens avec le nom MySQL ne sont pas parfaitement établis. Notre dossier
de base et un grand nombre de librairies et outils étaient préfixés par
``my'' depuis plus de 10 ans. Mais la fille de Monty, plus jeune que lui, était
aussi appelée My. Lequel des deux a conduit au nom de MySQL est toujours un
mystère, même pour nous.
Le nom du dauphin MySQL (notre logo) est Sakila, qui a été choisi par les
fondateurs de MySQL AB à partir d'une grande liste de noms suggérés par les
utilisateurs dans le concours "Name the Dolphin" ("Nommez le dauphin").
Le nom a été suggéré par Ambrose Twebaze, un développeur de softwares open source
de Swaziland, Afrique.
D'après Ambrose, le nom Sakila puise ses origines du SiSwati, la langue locale du
Swaziland. Sakila est aussi le nom d'une ville dans Arusha, Tanzanie, près
du pays d'origine d'Ambrose, Uganda.
La liste suivante décrit les caractéristiques principales du
logiciel de bases de données MySQL. See section 1.5 MySQL 4.0 In A Nutshell.
MySQL est vérifié avec Purify (un utilitaire de
détection des fuites mémoires commercial) ainsi qu'avec Valgrind,
un outil GPL (http://developer.kde.org/~sewardj/).
FLOAT, DOUBLE, CHAR, VARCHAR,
TEXT, BLOB, DATE, TIME, DATETIME,
TIMESTAMP, YEAR, SET et ENUM.
See section 6.2 Types de colonnes.
INSERT pour insérer un sous ensemble
de colonnes : les colonnes qui ne sont pas explicitement cités prennent
alors leur valeur par défaut.
SELECT
et la clause WHERE. Par exemple :
mysql> SELECT CONCAT(first_name, " ", last_name)
-> FROM tbl_name
-> WHERE income/dependents > 10000 AND age > 30;
GROUP BY et
ORDER BY. Support des fonctions de groupages
(COUNT(), COUNT(DISTINCT ...),
AVG(), STD(),
SUM(), MAX() et MIN()).
LEFT OUTER JOIN et RIGHT OUTER JOIN avec les
syntaxes ANSI SQL et ODBC.
DELETE, INSERT, REPLACE et UPDATE retourne
le nombre de lignes affectées. Il est possible d'obtenir le nombre de lignes
trouvées en modifiant une option lors de la connexion au serveur.
MySQL SHOW est utilisée pour obtenir
des informations sur les bases, tables et index. La commande EXPLAIN
sert à optimiser les requêtes.
ABS est un nom de colonne valide. La seule restriction est que,
lors d'un appel de fonction, aucun espace n'est toléré entre le nom de la fonction et
la parenthèse ouvrante `(' suivante. See section 6.1.7 Est-ce que MySQL est sensible aux mots réservés ?.
serveur MySQL
avec des bases qui contiennent 50 millions de lignes et nous connaissons des
utilisateurs qui utilisent le serveur MySQL avec plus de
60 000 tables and et 5 000 000 000 (milliards) de lignes.
serveur MySQL. Un index peut utiliser un préfixe issu d'un champs
CHAR ou VARCHAR.
MySQL en utilisant les sockets
TCP/IP, les sockets Unix (Unix) ou les Named Pipes (NT).
ODBC (Open-DataBase-Connectivity) pour Win32 (avec les sources).
Toutes les fonctions ODBC 2.5 et de nombreuses autres. Par exemple, vous pouvez
utiliser MS Access pour vous connecter au serveur MySQL. See section 8.3 Support ODBC avec MySQL.
MySQL
est démarré. Pour voir un exemple très avancé de tri, voyez le code
de tri pour le Tchèque. Le serveur MySQL supporte de nombreux jeux
de caractères qui peuvent être spécifié à la compilation et durant l'exécution.
myisamchk, un utilitaire rapide pour vérifier les tables,
les optimiser et les réparer. Toutes les fonctionnalités de myisamchk
sont aussi disponibles via l'interface SQL.
See section 4 Administration du serveur.
MySQL peuvent être appelés avec l'option --help
ou -? pour obtenir de l'aide en ligne.
Cette section répond aux questions ``Jusqu'à quel point MySQL est il stable ?'' et ``Puis-je faire confiance à MySQL pour mon projet ?'' Nous allons tenter d'apporter des réponses claires à ces questions importantes qui concernent tous les utilisateurs potentiels. Les informations de cette section sont fournies par les listes de diffusions, qui sont très actives et promptes à identifier les problèmes et les rapporter.
Le code original date du début des années 80 et fournit une base de
code stable, tout en assurant une compatibilité ascendante avec le
format ISAM.
A TcX, le prédécesseur de MySQL AB, le code de MySQL a fonctionné
sur des projets depuis la mi 1996, sans aucun problème. Lorsque le
Serveur MySQL a été livré à un public plus large, nous avons réalisé
qu'il contenait du code ``jamais testé'' qui a été rapidement identifié par les
utilisateurs, qui effectuait des requêtes différentes des nôtres. Chaque nouvelle
version avait moins de problèmes de portabilité, même si chaque nouvelle
version avait de nombreuses nouvelles fonctionnalités.
Chaque version du Serveur MySQL était parfaitement fonctionnelle.
Les seuls problèmes étaient rencontrés par les utilisateurs de
code de ces ``zone d'ombres''. Naturellement, les nouveaux utilisateurs
ne connaissent pas ces zones : cette section tente de les présenter,
dans la mesure de nos connaissances.
Les descriptions correspondent surtout aux versions 3.23 du Serveur MySQL.
Tous les bogues connus et rapportés ont été corrigés dans la dernière version,
à l'exception de ceux qui sont listés dans la section Bugs, qui sont
des problèmes de conception. See section 1.8.5 Erreurs connues, et limitations de MySQL.
La conception du serveur MySQL est faite en plusieurs couches,
avec des modules indépendants. Certains des modules les plus récents
sont listés ici, avec leur niveau de test :
MySQL 4.x.
InnoDB -- Stable (en 3.23 depuis 3.23.49)
InnoDB a été déclaré
stable en MySQL version 3.23, à partir de la version 3.23.49.
InnoDB est utilisé dans de grands systèmes complexes, avec
forte charge.
BDB -- Gamma
Berkeley DB est très stable, mais nous sommes encore
en train d'améliorer l'interface du gestionnaire transactionnel de
table BDB du serveur MySQL. Cela demande encore du temps
pour qu'il soit aussi bien testé que les autres types de tables.
FULLTEXT -- Beta
MySQL 4.0.
MyODBC 2.50 (utilise ODBC SDK 2.5) -- Gamma
MyISAM -- Gamma
MyISAM qui vérifie si la table a été correctement fermée lors
de l'ouverture, et qui exécute automatiquement la vérification
et réparation éventuelles de la table.
MyISAM pour MySQL 4.0 qui
permet des insertions plus rapides.
fcntl()). Dans ces cas, il faut
utiliser mysqld avec l'option --skip-external-locking.
Les problèmes sont connus sur certaines distributions Linux, et sur
SunOS lorsqu'il est utilisé avec des disques en mode NFS.
MySQL AB fournit un support de première qualité pour les clients
payant, mais les listes de diffusions de MySQL sont généralement
rapides à donner des réponses aux questions les plus communes. Les bogues
sont généralement corrigés aussitôt avec un patch. Pour les bogues
sérieux, il y a presque toujours une nouvelle version.
MySQL version 3.22 a une limite de 4Go par table. Avec le nouveau
format de table MyISAM, disponible avec MySQL version 3.23,
la taille maximale des tables a été poussée à 8 millions de teraoctets (2 ^ 63 octets).
Notez, toutefois, que les systèmes d'exploitation ont leur propres limites. Voici quelques exemples :
| Système d'exploitation | Limite |
| Linux-Intel 32 bit | 2Go, 4Go ou plus, suivant la version de Linux |
| Linux-Alpha | 8To (?) |
| Solaris 2.5.1 | 2Go (4Go possibles avec un patch) |
| Solaris 2.6 | 4Go (peut être modifié avec une option) |
| Solaris 2.7 Intel | 4Go |
| Solaris 2.7 UltraSPARC | 512Go |
En Linux 2.2, vous pouvez avoir des tables plus grandes que 2Go en utilisant le patch LFS pour les systèmes de fichiers ext2. En Linux 2.4, le patche existe aussi pour ReiserFS.
Cela signifie que les tables MySQL sont généralement limitées par
le système d'exploitation.
Par défaut, les tables MySQL peuvent atteindre une taille de 4Go.
Vous pouvez vérifier la taille des tables avec la commande SHOW TABLE STATUS
ou la commande en ligne myisamchk -dv nom_de_table.
See section 4.5.6 Syntaxe de SHOW.
Si vous avez besoin de tables plus grandes que 4Go (et que votre système
d'exploitation le supporte, modifiez les paramètres AVG_ROW_LENGTH et MAX_ROWS
lorsque vous créez votre table. See section 6.5.3 Syntaxe de CREATE TABLE. Vous pouvez aussi
les modifier ultérieurement avec ALTER TABLE. See section 6.5.4 Syntaxe de ALTER TABLE.
Si vos tables sont accessibles uniquement en lecture, vous pouvez aussi
utiliser l'utilitaire myisampack pour rassembler et compresser plusieurs
tables en une seule. myisampack compresse généralement la table
de près de 50%, ce qui vous augmente d'autant la taille maximale de la
table. See section 4.7.4 myisampack, le générateur de tables MySQL compressées en lecture seule.
Vous pouvez aussi contourner les limites du système d'exploitation
avec les tables MyISAM, en utilisant l'option RAID. See section 6.5.3 Syntaxe de CREATE TABLE.
Une autre solution est d'utiliser la librairie MERGE, qui permet de
gérer plusieurs tables comme une seule.
See section 7.2 Tables assemblées MERGE.
Le serveur MySQL lui même n'a aucun problème de compatibilité
avec l'an 2000 (Y2K) :
serveur MySQL utilise les fonctions de date Unix, et n'a aucun
problème avec les dates jusqu'en 2069; toutes les années écrites en
deux chiffres sont supposées faire partie de l'intervalle allant de
1970 à 2069, ce qui signifie que si vous stockez la date
01 dans une colonne de type year, le serveur MySQL la
traitera comme 2001.
MySQL sont stockées dans un fichier
`sql/time.cc', et sont codées très soigneusement pour être compatibles
avec l'an 2000.
MySQL version 3.22 et plus récent, le type de colonne YEAR
peut stocker les valeurs 0 et de 1901 à 2155 sur un seul
octet, tout en affichant 2 ou 4 chiffres.
Vous pouvez rencontrer des problèmes avec les applications qui utilisent le serveur MySQL
sans être compatible avec l'an 2000. Par exemple, les vieilles applications
utilisent des valeurs d'années sur deux chiffres (ce qui est ambigu), plutôt
qu'avec 4 chiffres. Ce problème peut être complété par des applications qui
utilisent des valeurs telles que 00 ou 99 comme indicateur
de données ``manquante''.
Malheureusement, ces problèmes peuvent se révéler difficiles à corriger car différentes applications peuvent être écrites par différents programmeurs, et chacun utilise un jeu différent de conventions et de fonctions de gestion des dates.
Voici une illustration simple qui montre que le serveur MySQL
n'a aucun problème avec les dates jusqu'en 2030 :
mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE y2k (date DATE,
-> date_time DATETIME,
-> time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO y2k VALUES
-> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
-> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
-> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
-> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
-> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
-> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
-> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
-> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
-> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
-> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
-> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
-> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
-> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date | date_time | time_stamp |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)
Cet exemple montre que les types DATE et DATETIME ne poseront
aucun problème avec les dates futures (ils gèrent les dates jusqu'en 9999).
Le type TIMESTAMP, qui est utilisé pour stocker la date courante,
est valide jusqu'en 2030-01-01. TIMESTAMP va de
1970 en 2030 sur les machines 32 bits (valeur signée). Sur les
machines 64 bits, il gère les dates jusqu'en 2106 (valeur non signée).
Même si le serveur MySQL est compatible an 2000, il est de votre responsabilité
de fournir des données non ambiguës. Voyez section 6.2.2.1 An 2000 et les types date pour les règles du
serveur MySQL pour traiter les dates ambiguës (les données contenant des
années exprimées sur deux chiffres).
MySQL AB est l'entreprise des fondateurs de MySQL et les
principaux développeurs. A l'origine, MySQL AB a été établie
en Suède, par David Axmark, Allan Larsson et Michael Monty Widenius.
Tous les développeurs du serveur MySQL sont employés par l'entreprise.
Nous sommes une organisation virtuelle, avec des employés répartis dans
une douzaine de pays à travers le monde. Nous communiquons intensivement
entre nous sur l'Internet tous les jours, et avec nos utilisateurs,
fans et partenaires.
Nous nous consacrons au développement du logiciel MySQL et à
la diffusion de notre base de données auprès des nouveaux utilisateurs.
MySQL AB est propriétaire des droits du code source de
MySQL, du logo MySQL et de la marque de commerce,
ainsi que du manuel. See section 1.2 Qu'est ce que MySQL?.
Les valeurs fondamentales de MySQL témoignent de notre
implication auprès de MySQL et des
Logiciels libres.
Nous souhaitons que la base de données MySQL soit :
MySQL AB et les collaborateurs de MySQL AB :
logiciels libres et supportent la communauté
des Logiciels libres.
Le site web de MySQL (http://www.mysql.com/)
fournit les dernières informations à propos de MySQL et MySQL AB.
Une des questions les plus fréquentes que nous rencontrons est : ``Comment arrivez-vous à vivre en développant un produit gratuit ?'' Voici comment.
MySQL AB fait des affaires en vendant du support, des services,
des licences commerciales et en percevant des royalties. Nous utilisons
ces fonds pour le développement des produits et des affaires de
MySQL.
La compagnie est profitable depuis sa conception. En octobre 2001, nous avons accepté un financement de la part d'un groupe d'investisseurs scandivanes important et de quelques business angels. Cet investissement est utilisé pour consolider notre modèle d'affaires et assurer les bases de notre croissance à long terme.
MySQL AB est dirigé par ses propriétaires, qui sont les fondateurs
et les principaux développeurs de la base de données MySQL. Les
développeurs se consacrent au support des utilisateurs et des autres
utilisateurs, afin de rester au courant de leurs besoins et leurs problèmes.
Tout notre support est donné par des développeurs qualifiés. Les
questions vraiment épineuses sont étudiées par Michael Monty Widenius,
auteur principal du code du serveur MySQL.
See section 1.4.1 Support proposé par MySQL AB.
Pour plus d'informations et pour commander un support de différents niveaux, voyez http://www.mysql.com/support/ ou contactez notre équipe de vente à sales@mysql.com.
MySQL AB organise des formations MySQL à travers le monde entier.
Nous offrons des cours inter et intra entreprise, adaptés aux besoins spécifiques
de chaque société. La formation MySQL est aussi disponible auprès de
nos partenaires, les centres de formation certifiés MySQL.
Nos documents de formation utilisent les mêmes exemples de bases de données
que notre documentation et nos applications d'exemple, et ils sont toujours
mis à jour pour prendre en compte les dernières versions de MySQL.
Nos formateurs sont épaulés par notre équipe de développement pour garantir la
qualité de la formation et le développement continu des documents de cours.
Cela vous assure aussi qu'il n'y aura pas de questions laissées ouvertes
durant les cours.
Suivre nos formations vous permettra d'atteindre tous vos buts avec
votre application MySQL. Vous allez aussi :
certification MySQL.
Si vous êtes intéressé par nos formations, en tant que participant potentiel, ou comme partenaire de formation, visitez la section de formation à http://www.mysql.com/training/ ou contactez-nous à : training@mysql.com.
Le programme de certification MySQL est publié dans le second
semestre 2002. Pour plus de détails, voyez
http://www.mysql.com/certification/.
MySQL AB et ses partenaires accrédités offrent des
services de conseil aux utilisateurs du serveur MySQL et
à ceux qui intègrent le serveur MySQL dans leurs logiciels, à
travers le monde.
Nos consultants peuvent vous aider à concevoir et paramétrer vos
bases, construire des requêtes efficaces, optimiser votre plate-forme,
résoudre les problèmes de migration, installer la réplication,
bâtir des applications transactionnelles robustes et bien plus encore.
Nous aidons aussi les clients à intégrer le serveur MySQL dans
leurs produits et applications, pour un déploiement d'envergure.
Nos consultants travaillent en collaboration étroite avec notre équipe
de développement pour assurer la qualité technique de nos
services professionnels. Les missions de conseil peuvent aller de
sessions de démarrage de deux jours à des projets de plusieurs semaines
ou mois. Notre expertise couvre non seulement le serveur MySQL,
mais s'étend aussi aux langages de programmation tels que PHP, Perl et
d'autres encore.
Si vous êtes interessé par nos services de conseil ou si vous souhaitez devenir un partenaire conseil, visitez la section conseil de notre site web à http://www.mysql.com/consulting/ ou contactez notre équipe de conseil à consulting@mysql.com.
La base de données MySQL est publiée sous la licence
GNU General Public License (GPL).
Cela signifie que le logiciel MySQL peut être utilisé gratuitement,
en acceptant les termes de la licence GPL. Si vous ne voulez pas
être lié par les termes de la licence GPL (comme le fait que
votre application aussi doit être GPL), vous pouvez acheter une licence
du même produit auprès de MySQL AB.
Voyez http://www.mysql.com/support/arrangements/price.html.
Comme MySQL AB est propriétaire du copyright du code source de MySQL,
nous pouvons utiliser une double licence, qui fait que le même produit
est disponible sous la licence GPL et sous une licence commerciale.
Cela ne change en rien l'implication de MySQL AB dans le
mouvement des logiciels libres. Pour plus de détails sur quand
une licence commerciale est nécessaire, voyez section 1.4.3 Licences MySQL.
Nous vendons aussi des licences commerciales aux logiciels Open Source GPL
qui ajoutent à la valeur du serveur serveur MySQL. Un bon exemple est
le gestionnaire de table transactionnel InnoDB qui offre le support
ACID, le verrouillage de ligne, la restauration après crash, le
multi versionnage, le support des clés étrangères, etc.
See section 7.5 Tables InnoDB.
MySQL AB a un programme de partenariat mondial qui couvre la formation,
le conseil et le support, les publications, la revente et la distribution des
produits MySQL. Les partenaires MySQL AB gagnent en visibilité
grâce au site http://www.mysql.com/ et le droit d'utiliser certaines
versions spéciales des marques de commerce MySQL pour identifier
leurs produits et promouvoir leur entreprise.
Si vous êtes intéressé à devenir un partenaire MySQL AB, envoyez un
email à partner@mysql.com.
Le mot MySQL et le logo MySQL avec le dauphin sont des
marques commerciales de MySQL AB. See section 1.4.4 Logos MySQL AB et marque déposée.
Ces marques représentent un investissement capital que les fondateurs
de MySQL ont placé depuis plusieurs années.
Le site web MySQL (http://www.mysql.com/) est très populaire auprès
des développeurs et des utilisateurs. En Octobre 2001, nous avons eu 10 millions de pages vues.
Nos visiteurs représentent un groupe effectuant des décisions d'achat et des recommandations
pour le matériel et les logiciels. Douze pour cents de nos visiteurs émettent des décisions d'achat,
et seulement 9 % n'en prennent pas du tout. Plus de 65 % d'entre eux ont effectué un
ou plusieurs achats sur internet ces six derniers mois, et 70 % prévoient d'en faire un dans le mois à venir.
Le site web de MySQL (http://www.mysql.com/)
fournit les dernières informations à propos de MySQL et
MySQL AB.
Pour les contacts presse et les questions qui ne sont pas couvertes par les annonces officielles (http://www.mysql.com/news/), envoyez un email à press@mysql.com.
Si vous avez un contrat de support valide avec MySQL AB, vous obtiendrez
des réponses rapides et précises de notre équipe technique sur le
logiciel MySQL. Pour plus d'informations, voyez section 1.4.1 Support proposé par MySQL AB.
Sur notre site web, voyez http://www.mysql.com/support/,
ou envoyez un email à sales@mysql.com.
Pour des informations sur les formations MySQL, visitez la
section formation à http://www.mysql.com/training/. Si vous
avez un accès restreint à Internet, contactez l'équipe de formation
de MySQL AB à l'adresse training@mysql.com.
See section 1.3.1.2 Formation et certification.
Pour des informations sur le programme de certification MySQL,
voyez la section http://www.mysql.com/certification/.
See section 1.3.1.2 Formation et certification.
Si vous êtes interessé par du conseil, visitez la section conseil
à http://www.mysql.com/consulting/. Si vous avez un accès restreint
à Internet, contactez l'équipe de conseil de MySQL AB
à consulting@mysql.com.
See section 1.3.1.3 Conseil.
Les licences commerciales peuvent être commandées en ligne à
http://order.mysql.com/. Vous trouverez aussi des informations
sur les commandes par fax à MySQL AB. Plus d'informations sur les
licences sont disponibles à
http://www.mysql.com/products/pricing.html.
Si vous avez des questions qui concernent les licences ou que vous
souhaitez un devis pour un achat de nombreuses licences, remplissez
le formulaire de contact disponible sur le site web
(http://www.mysql.com/) ou envoyez un email à
licensing@mysql.com (pour les questions de licence) ou à
sales@mysql.com (pour les devis).
See section 1.4.3 Licences MySQL.
Si vous représentez une entreprise qui est interessée par un partenariat
avec MySQL AB, envoyez un email à partner@mysql.com.
See section 1.3.1.5 Partenariats.
Pour plus d'informations sur la politique de marque de commerce de MySQL,
reportez-vous à http://www.mysql.com/company/trademark.html ou
envoyez un email à trademark@mysql.com.
See section 1.4.4 Logos MySQL AB et marque déposée.
Si vous êtes interessé par un des emplois à MySQL AB présentés dans notre
section job (http://www.mysql.com/company/jobs/),
envoyez un email à jobs@mysql.com.
N'envoyez pas votre CV en pièce jointe, mais collez-le dans le corps du texte
à la fin de votre message.
Pour des discussions générales entre utilisateurs, dirigez vos questions sur la liste de diffusion appropriée. See section 1.7.1 Listes de diffusion MySQL.
Les rapports d'erreurs (aussi appelés bogues), ainsi que les questions
et suggestions doivent être envoyés à la liste de diffusion
mysql@lists.mysql.com. Si vous avez trouvé un trou de sécurité
critique dans le serveur MySQL, envoyez votre courriel
à security@mysql.com.
See section 1.7.1.3 Comment rapporter un bogue ou un problème.
Si vous avez un résultat de test que nous pouvons publier, contactez-nous à benchmarks@mysql.com.
Si vous avez des suggestions concernant les améliorations ou les corrections de ce manuel, envoyez-les à l'équipe du manuel docs@mysql.com. Pour les remarques spécifiques à la version française, vous pouvez aussi contacter directement Damien Seguy à damien.seguy@nexen.net.
Pour les questions ou commentaires à propos du fonctionnement
ou du contenu du site web MySQL (http://www.mysql.com/),
envoyez un email à webmaster@mysql.com.
MySQL AB a une politique de protection des données privées
qui est présentée à http://www.mysql.com/company/privacy.html.
Pour toutes les questions concernant cette politique,
envoyez un email à privacy@mysql.com.
Pour toutes les autres questions, envoyez un email à info@mysql.com.
Cette section décrit le support MySQL et les accords de licence.
Le support technique de MySQL AB est la réponse individualisée
à vos problèmes particuliers, en direct, de l'équipe d'ingénieurs qui
programme la base de données MySQL.
Nous tâchons d'avoir un support technique exhaustif et global. Presque
tous les problèmes qui impliquent MySQL sont importants pour nous,
s'ils sont importants pour vous.
Typiquement, les clients qui recherchent de l'aide sur les différentes
commandes, qui souhaitent résoudre des problèmes de performance,
réparer des systèmes corrompus, comprendre les impacts des
systèmes d'exploitation ou des réseaux sur les performances de
MySQL, mettre en place des bonnes pratiques pour la sauvegarde
et l'entretien, utiliser les APIs, etc.
Notre support couvre uniquement le serveur MySQL et nos propres
utilitaires, pas les produits tiers d'entreprises qui accèdent
au serveur MySQL, même si nous pouvons parfois aider.
Les informations détaillées sur les différents niveaux de support sont disponibles à http://www.mysql.com/support/, et les contrats de support peuvent aussi être commandés en ligne. Si vous avez un accès restreint à Internet, vous pouvez contacter notre équipe commerciale à sales@mysql.com.
Le support technique est identique à l'assurance vie. Vous pouvez vivre
très heureux sans pendant plusieurs années, mais lorsque vous rencontrerez
une catastrophe, il sera trop tard pour l'acheter. Si vous utilisez
MySQL pour des applications importantes et que vous rencontrez des
problèmes, cela peut vous prendre très longtemps pour comprendre par vous-
même. Vous pourriez alors avoir besoin de communiquer avec les
techniciens les plus expérimentés de MySQL, ceux qui sont
employés par MySQL AB.
MySQL AB est propriétaire du copyright du code source de MySQL,
des logos MySQL, de la marque de commerce et de ce manuel.
See section 1.3 Qui est MySQL AB ?.
Plusieurs licences distinctes sont disponibles pour la diffusion de MySQL :
MySQL pour le serveur, le client mysqlclient
et la librairie, ainsi que la librairie GNU readline sont couverts par la
licence GNU General Public License.
See section G Licence Publique Générale GNU.
Le texte de cette licence est aussi disponible dans le fichier intitulé
`COPYING' dans les distributions.
GNU getopt est sous la licence
GNU Lesser General Public License.
See section H Licence Publique Générale GNU Limitée.
regexp) sont placées sous
un copyright de type Berkeley.
MySQL (3.22 et plus récentes) sont sujettes à
des licences plus strictes
(http://www.mysql.com/support/arrangements/mypl.html).
Voyez la documentation spécifique de chaque version pour plus de détails.
GPL. L'utilisation du manuel est sujette à ces conditions :
MySQL AB.
Pour plus de détails sur comment les licences MySQL fonctionnent,
voyez section 1.4.3 Licences MySQL.
Voyez aussi section 1.4.4 Logos MySQL AB et marque déposée.
Le logiciel MySQL est publié sous la licence
GNU General Public License (GPL),
qui est probablement mieux connue sous le nom de Open Source.
Les termes exacts de la licence GPL sont disponibles sur le site
de http://www.gnu.org/licenses/.
Voyez aussi http://www.gnu.org/licenses/gpl-faq.html et
http://www.gnu.org/philosophy/enforcing-gpl.html.
Comme le logiciel MySQL est publié sous la licence GPL,
il est souvent utilisé gratuitement, mais pour certains usages vous
souhaiterez peut-être acheter une licence commerciale auprès de
MySQL AB à http://order.mysql.com/.
Voyez http://www.mysql.com/support/arrangements.html pour plus
d'informations.
Les anciennes versions de MySQL (3.22 et plus anciennes) sont sujettes
à une licence plus stricte
(http://www.mysql.com/support/arrangements/mypl.html).
Voyez la documentation spécifique de chaque version pour information.
Notez bien que l'utilisation du logiciel MySQL sous une licence
commerciale. GPL, ou toute autre ancienne licence MySQL ne
vous donne pas automatiquement le droit d'utiliser les marques commerciales
de MySQL AB.
See section 1.4.4 Logos MySQL AB et marque déposée.
La licence GPL est contagieuse, dans le sens où lorsqu'un programme
est lié à la licence GPL, toutes les sources de toutes les parties
du produit final doivent aussi être publiée sous la licence GPL.
Sinon, vous violez la licence, et annulez vos droits d'utiliser le
programme GPL.
Vous avez besoin d'une licence commerciale pour :
GPL issu de MySQL
et que vous ne voulez pas que le produit final soit publié sous la licence
GPL, peut être parce que vous souhaitez publier un produit commercial
ou conserver du code non-GPL pour d'autres raisons. Lorsque vous achetez
une licence commerciale vous n'utilisez plus MySQL sous la licence
GPL, même si c'est le même code.
GPL qui fonctionne
uniquement avec MySQL, et que vous distribuez cette application
avec MySQL. Ce type de solution est considéré comme un lien,
même si c'est fait via le réseau.
MySQL sans fournir le code
source original, comme requis par la licence GPL.
MySQL
même si vous n'avez pas besoin formellement de la licence commerciale.
Acheter du support auprès de MySQL AB est une autre bonne solution
pour contribuer au développement de MySQL, avec des avantages directs
pour vous.
See section 1.4.1 Support proposé par MySQL AB.
Si vous avez besoin d'une licence, vous en aurez besoin d'une pour chaque
installation de MySQL. Cela est valable quelque soit le nombre de
processeurs de la machine, et il n'y a pas de limite artificielle de
nombre de connexion simultanées.
Pour les licences commerciales, voyez notre site web http://www.mysql.com/support/arrangements/price.html. Pour les contrats de support, voyez http://www.mysql.com/support/. Si vous avez des besoin spéciaux, ou que vous avez un accès restreint à internet, contactez notre équipe de vente à sales@mysql.com.
Vous pouvez utiliser le logiciel MySQL sous la licence gratuite GPL
si vous acceptez les termes et conditions de la licence GPL.
Pour une liste exhaustive des questions courantes à propos de
la licence GPL, voyez la FAQ générale de la Free Software Foundation à
http://www.gnu.org/licenses/gpl-faq.html.
Quelques cas courants :
MySQL,
ensemble avec la licence GPL.
MySQL avec d'autres
programmes qui ne sont pas liés ou dépendant de MySQL pour leur
fonctionnalités, même si vous vendez la distribution commercialement.
Ceci s'appelle une agrégation simple en termes GPL.
MySQL,
vous pouvez l'utiliser gratuitement.
MySQL.
Cependant, nous vous encourageons à faire affaires avec un ISP qui
dispose du support MySQL, car cela vous donne l'assurance que si
votre hébergeur a des problèmes avec l'installation de MySQL,
votre hébergeur aura les ressources pour résoudre votre problème.
Notez que si votre ISP n'a pas de licence commerciale pour le
le MySQL, il devrait au moins fournir l'accès en lecture
aux sources aux clients pour qu'ils vérifient que l'installation de
MySQL est correctement patchée.
MySQL en conjonction
avec un serveur web, vous n'avez pas besoin de licence commerciale (aussi longtemps
que ce n'est pas un produit que vous distribuez). Ceci est même vrai si vous
avec un serveur web qui utilise le serveur MySQL, car vous ne
distribuez pas de partie de MySQL. Cependant, dans ce cas, nous vous
demandons d'acheter du support MySQL car
MySQL aide votre entreprise
Si vous utilisez le serveur de bases de données MySQL sans avoir
besoin de licence commerciale, nous vous encourageons à acheter le support
auprès de MySQL AB malgré tout. De cette façon, vous contribuez
au développement de MySQL et en obtenez des avantages immédiats
vous-même. See section 1.4.1 Support proposé par MySQL AB.
Si vous utilisez MySQL dans un contexte commercial tel que vous en tirez
profit, nous vous demandons de participer au développement de MySQL
en achetant du support. Nous pensons que comme MySQL aide votre
entreprise, il est raisonnable de vous demander d'aider à votre tour
MySQL AB.
(Sinon, lorsque vous nous posez des questions de support, non seulement vous
utilisez gratuitement un système dans lequel nous avons investi beaucoup
de temps, mais en plus, vous nous demandez du support gratuit, en plus !)
Beaucoup d'utilisateurs de MySQL souhaitent afficher le logo du dauphin
MySQL AB sur leur sites web, leur livres ou leurs produits. Nous encourageons
ces actes, tant qu'on part du principe que le mot MySQL et le logo du dauphin
MySQL sont des marques déposées par MySQL AB et ne doivent être utilisés
que dans les conditions décrites à la page suivante : http://www.mysql.com/company/trademark.html.
Le dauphin MySQL a été conçu par l'agence de publicité finlandaise
Priority, en 2001. Le dauphin a été choisi en tant que symbole représentatif
de MySQL, car c'est un animal intelligent, rapide et élancé,
qui parcourt sans effort l'océan des données. Nous aimons aussi les dauphins.
Le logo original de MySQL ne peut être utilisé que par les représentants
de MySQL AB et par ceux qui ont un accord signé leur permettant de le faire.
Nous avons conçu un jeu de logos qui peuvent être utilisés sous conditions, et
qui peuvent être téléchargés depuis notre site web à
http://www.mysql.com/press/logos.html
et utilisés sur les sites web tiers sans autorisation écrite de
MySQL AB.
L'utilisation de ces logos n'est pas inconditionnelle, mais, comme
leur nom l'implique, sujette à notre politique de marque de commerce
qui est aussi disponible sur notre site web. Il est recommandé de lire
ce document avant d'utiliser les logos sur votre site web. En bref, les
pré-requis sont :
MySQL AB,
êtes le créateur de ce site, qui arbore les couleurs de MySQL.
MySQL AB
ou aux valeurs de MySQL AB. Nous nous réservons le droit de
retirer notre autorisation d'utiliser le logo de MySQL AB.
MySQL sous licence GPL dans
votre application, votre application doit porter la mention Open Source
et être capable de se connecter à un serveur MySQL.
Contactez-nous à trademark@mysql.com pour voir avec nous tous les arrangements spéciaux qui vous conviendraient.
Dans les cas suivants vous devez obtenir une permission écrite de MySQL AB
avant d'utiliser les logos MySQL :
MySQL AB n'importe où, en dehors de
votre site web.
MySQL AB hormis les logos
à utilisation conditionnée mentionnés auparavant sur le
site web, ou ailleurs
En dehors des raisons commerciales et légales, nous nous devons de suivre
l'utilisation du logo MySQL sur les produits, livres, etc. Nous demanderons
une compensation pour l'affichage des logos MySQL AB sur les produits,
car nous pensons qu'il est raisonnable qu'une partie des revenus ainsi générés
servent à poursuivre le développement de la base de données MySQL.
Le logo partenariat MySQL ne doit être utilisé que par les compagnies
et les personnes ayant un partenariat écrit avec MySQL AB
Le partenariat inclut une certification en tant que consultant ou professeur MySQL.
Merci de visiter section 1.3.1.5 Partenariats.
MySQL sur des documents imprimés ou des présentations
MySQL AB apprécie les références à la base MySQL. Il faut
toutefois garder à l'esprit que MySQL est une marque commerciale,
propriété de MySQL AB. A cause de cela, il faut ajouter au logo
le symbole de marque de commerce (TM) lors de la première ou de la
plus visible utilisation du mot MySQL dans le texte et, là où
approprié, établir clairement que MySQL est une marque commerciale
de MySQL AB. Reportez-vous à notre politique de marque commerciale
à http://www.mysql.com/company/trademark.html pour plus de détails.
MySQL dans un nom de société ou de produit
L'utilisation du mot MySQL dans le nom d'une compagnie, d'un produit
ou d'un nom de domaine Internet est interdite sans une permission écrite de
MySQL AB.
Promise depuis longtemps par MySQL AB et attendue avec
impatience par nos utilisateur, le serveur MySQL 4.0 est
disponible en version de production.
MySQL 4.0 est disponible au téléchargement depuis http://www.mysql.com/ et nos mirroirs. MySQL 4.0 a été testée par un grand nombre d'utilisateurs et il est en production sur de très grands sites.
Les fonctionnalités principales de MySQL serveur 4.0 sont destinées à nos utilisateurs professionnels et communautaire : elles améliorent le capacités de MySQL pour gérer les missions critiques et les systèmes fortement chargés. D'autres fonctionnalités sont destinées aux utilisateurs de solutions intégrées.
MySQL version 4.0.12 a été déclarée stable pour utilisation en production, en mars 2003. Cela signifie que désormais, seules les corrections de bugs pour la série 4.0 seront faites. Les corrections de bugs critiques pour les séries 3.23 seront aussi proposées. See section 2.5.3 Passer de la version 3.23 à la version 4.0.
Les nouvelles fonctionnalités sont ajoutées en MySQL 4.1, qui est désormais disponibles sur notre serveur de versions BitKeeper. See section 1.6 MySQL 4.1 In A Nutshell.
INSERT de masse, la recherche sur les
index compressés, la création d'index FULLTEXT ainsi que les comptes
COUNT(DISTINCT).
InnoDB en standard
InnoDB est désormais livré en standard avec le
serveur MySQL, apportant le support complet des transactions ACID,
les clés étrangères avec modifications et effacement en cascade,
ainsi que le verrouillage de ligne.
See section 7.5 Tables InnoDB.
FULLTEXT de MySQL Server 4.0
permettent l'utilisation d'index FULLTEXT sur de grandes quantités de
texte, avec des logiques binaires ou en langage naturel. Les utilisateurs peuvent
paramétrer la taille minimum des mots, et définir leur propre liste de mots
interdits, dans n'importe quel langue. Cela ouvre la possibilité de nombreuses
applications avec MySQL Server.
See section 6.8 Recherche en Texte-entier (Full-text) dans MySQL.
TRUNCATE TABLE (comme sous Oracle) et
IDENTITY comme synonyme pour les clés automatiquement incrémentées
(comme sous Sybase).
UNION, une fonctionnalité SQL attendue
avec impatience.
latin1_de, qui corrige les problèmes
de tri des valeurs allemandes, en plaçant les umlauts allemands dans
le même ordre que dans l'annuaire d'Allemagne.
mysqld
peuvent être modifiées sans redémarrer le serveur. See section 5.5.6 Syntaxe de SET.
DELETE et UPDATE peuvent désormais fonctionner
sur plusieurs tables.
liens symboliques à MyISAM au niveau
des tables (et non plus au niveau des bases, comme auparavant), et en
autorisant les liens symboliques sur Windows, nous espérons que nous
avons pris au sérieux vos demandes d'amélioration.
SQL_CALC_FOUND_ROWS et FOUND_ROWS() rendent
possible le comptages de lignes sans utiliser la clause LIMIT.
La section sur les nouveautés du manuel rassemble toutes les nouveautés. See section C.3 Changements dans la publication 4.0.x (Beta).
libmysqld rend le serveur MySQL disponible pour toute une gamme
d'applications très vaste. En utilisant la librairie du serveur
MySQL intégré, vous pouvez utiliser MySQL dans différentes applications
et appareillages, où l'utilisateur final n'aura même pas idée
de sa présence. Le serveur MySQL intégré est idéal pour équiper les
bornes internet, les kiosques publics, les packages matériel/
logiciels clé en main, les serveurs MySQL haute performances,
et les bases de données autonomes sur CDrom.
De nombreux utilisateurs de libmysqld profiteront de la
double licence. Pour ceux qui ne souhaitent pas être liés par
la licence GPL, la librairie est aussi disponible avec une
licence commerciale. La librairie MySQL intégrée utilise la même
interface que la librairie cliente classique, ce qui la rend
pratique à utiliser. See section 8.4.15 libmysqld, la librairie du serveur embarqué MySQL.
MySQL Server 4.0 a posé les fondations pour de nouvelles fonctionnalités telles que les sous-requêtes imbriquées et l'Unicode qui sont dors et déjà implémentée en version 4.1, ainsi que les procédures stockées SQL-99, qui seront disponibles pour la version 5.0. Ils représentent les fonctionnalités les plus demandées par de nombreux clients.
Avec ces améliorations, les critiques du serveur de base de données MySQL devront être plus imaginatifs que jamais pour identifier des manques dans le serveur MySQL. Déjà connu depuis longtemps pour sa stabilité, sa rapidité et sa facilité d'emploi, le serveur MySQL va désormais satisfaire la liste de tous les voeux des clients les plus exigents.
Les fonctionnalités ci-dessous sont implémentées en MySQL 4.1. Quelques autres fonctionnalités sont prévues pour MySQL 4.1, mais très peu. See section 1.9.1 New Features Planned For 4.1.
Les plus récentes fonctionnalités en cours de réalisation, comme par exemple les procédures stockées, seront disponibles en MySQL 5.0. See section 1.9.2 New Features Planned For 5.0.
SELECT * FROM t1 WHERE t1.a=(SELECT t2.b FROM t2); SELECT * FROM t1 WHERE (1,2,3) IN (SELECT a,b,c FROM t2);
FROM d'une commande SELECT :
SELECT t1.a FROM t1, (SELECT * FROM t2) t3 WHERE t1.a=t3.a;
BTREE pour les tables HEAP, ce qui
améliore significativement le temp de réponse pour les recherches
non exactes.
CREATE TABLE table LIKE table vous permet de créer une nouvelle
table avec la même structure que la table d'origine, dans la même commande.
SHOW WARNINGS affiche les erreurs de la dernière commande.
See section 4.5.6.9 SHOW WARNINGS | ERRORS.
HELP command coté serveur, qui peut être utilisée en ligne de commande
du client mysql et d'autres clients, pour obtenir de l'aide
sur les commandes SQL. Avec ces informations sur le serveur, elles
seront parfaitement adaptées à la version et configuration du serveur.
INSERT ... ON DUPLICATE KEY UPDATE .... Elle vous permet
de modifier une ligne avec UPDATE, si l'insertion
INSERT avait généré un double dans la colonne PRIMARY ou
UNIQUE.
See section 6.4.3 Syntaxe de INSERT.
La section sur les nouveautés du manuel rassemble toutes les nouveautés. See section C.2 Changes in release 4.1.x (Alpha).
De nouvelles fonctionnalités sont ajoutées à MySQL 4.1, qui est déjà disponible dans notre système BitKeeper. See section 2.3.4 Installer à partir de l'arbre source de développement.
Le jeu de fonctionnalités destiné à la version 4.1 est globalement définitif. Les nouveautés iront essentiellement à la nouvelle version de développement 5.0. MySQL 4.1 va suivre son développement normal avec une phase Alpha (durant laquelle de nouvelles fonctionnalités peuvent être ajoutées ou modifiées), puis Beta (où les fonctionnalités sont fixées, et seules des corrections sont faîtes), puis Gamma (qui indique qu'une version de production verra le jour dans quelques semaines), avant que la version 4.1 ne deviennent la nouvelle version officielle.
Il est recommandé aux utilisateurs de ne pas passer leurs systèmes en production sous le serveur MySQL 4.x, jusqu'à ce qu'elle soit publiée en phase béta (telle que la 4.0.3 beta). Toutefois, même la version initiale a passé avec succès notre batterie de tests, sans aucune erreur sur aucune plate-forme que nous avons utilisé. Etant donné le grand nombre de fonctionalités supplémentaires, nous recommandons le serveur MySQL, même en version alpha, pour les phases de développement. L'agenda de publication du serveur MySQL 4.x est tel qu'il atteindra un état stable avant les applications qui sont aujourd'hui en phase de développement.
Les nouveaux développements de MySQL sont désormais concentrés sur la version 5.0. Les procédures stockées et d'autres fonctionnalités seront en vedette. See section 1.9.2 New Features Planned For 5.0.
Cette section vous présente les listes de diffusions MySQL, et donne des conseils quand à leur utilisation. En vous inscrivant à une des listes de diffusion, vous recevrez les messages que les autres auront envoyé, et vous pourrez envoyer vos propres questions et réponses.
Pour vous inscrire à la liste de diffusion principale de MySQL, envoyez un courrier électronique à mysql-subscribe@lists.mysql.com.
Pour vous désinscrire à la liste de diffusion principale de MySQL, envoyez un courrier électronique à mysql-unsubscribe@lists.mysql.com.
Seule l'adresse d'où vous envoyez votre message est importante. La ligne de sujet et le corps sont ignorés.
Si votre adresse de réponse n'est pas valide, vous pouvez spécifier
votre adresse explicitement, en ajoutant un tiret après le mot
subscribe ou unsubscribe, suivi de votre adresse dans laquelle vous aurez
remplacé le caractère `@' par `='. Par exemple, pour inscrire
l'adresse your_name@host.domain, envoyez un message à
mysql-subscribe-your_name=host.domain@lists.mysql.com.
Les mails envoyés à mysql-subscribe@lists.mysql.com et mysql-unsubscribe@lists.mysql.com sont géré automatiquement par le robot ezmlm. Des informations sur ezmlm sont disponibles à http://www.ezmlm.org/.
Pour poster un message sur la liste elle-même, envoyez votre message à
mysql@lists.mysql.com. Toutefois, n'envoyez pas de mail
d'inscription ou de désinscription à mysql@lists.mysql.com car
tous les mails envoyés à cette adresse sont distribués automatiquement
à des milliers d'utilisateurs.
Votre site local peut avoir beaucoup d'inscrits à la liste mysql@lists.mysql.com.
Si c'est le cas, vous pouvez avoir une liste de diffusion locale, de façon
à ce que les messages envoyés par lists.mysql.com à votre site
local soit propagés par votre serveur local. Dans ce cas, contactez votre
administrateur local pour être ajouté ou retiré de la liste.
Si vous voulez que le trafic de cette liste soit envoyé à une autre
boîte aux lettres de votre client mail, installez un filtre basé sur les
entêtes du message. Vous pouvez utiliser notamment les entêtes List-ID: et
Delivered-To: pour identifier les messages de la liste.
Les listes de diffusion MySQL suivantes existent :
announce-subscribe@lists.mysql.com announce
mysql-subscribe@lists.mysql.com mysql
mysql-digest-subscribe@lists.mysql.com mysql-digest
mysql en format journalier. Cela signifie que vous
recevrez tous les messages de la journée en un seul gros email.
bugs-subscribe@lists.mysql.com bugs
mysqlbug
(si vous utilisez Windows, il faut aussi inclure la description du système
d'exploitation et la version de MySQL MySQL).
De préférence, vous devriez tester le problème avec la dernière version stable
ou de développement du serveur MySQL avant de l'envoyer. Tout le monde doit être
capable de reproduire le bogue simplement avec la ligne de commande
mysql test < script avec le cas de test inclus. Tous les bogues doivent
être posté sur la liste, et seront corrigés ou documentés dans la prochaine
version de MySQL!. Si les modifications sont trop petites, nous publierons
aussi un patch qui résout le problème.
bugs-digest-subscribe@lists.mysql.com bugs-digest
bugs en format journalier.
internals-subscribe@lists.mysql.com internals
internals-digest-subscribe@lists.mysql.com internals-digest
internals en format journalier.
java-subscribe@lists.mysql.com java
java-digest-subscribe@lists.mysql.com java-digest
java en format journalier.
win32-subscribe@lists.mysql.com win32
win32-digest-subscribe@lists.mysql.com win32-digest
win32 en format journalier.
myodbc-subscribe@lists.mysql.com myodbc
myodbc-digest-subscribe@lists.mysql.com myodbc-digest
myodbc en format journalier.
mysqlcc-subscribe@lists.mysql.com mysqlcc
MySQL Control Center.
mysqlcc-digest-subscribe@lists.mysql.com mysqlcc-digest
mysqlcc en format journalier.
plusplus-subscribe@lists.mysql.com plusplus
plusplus-digest-subscribe@lists.mysql.com plusplus-digest
plusplus en format journalier.
msql-mysql-modules-subscribe@lists.mysql.com msql-mysql-modules
msql-mysql-modules-digest-subscribe@lists.mysql.com msql-mysql-modules-digest
msql-mysql-modules en format journalier.
Vous pouvez vous inscrire ou vous désinscrire de toutes les listes en
même temps de la même façon que nous l'avons décrit au début. Dans votre
message d'inscription, utilisez simplement le nom de liste approprié.
Par exemple, pour vous inscrire à la liste myodbc, envoyez un
message à myodbc-subscribe@lists.mysql.com ou
myodbc-unsubscribe@lists.mysql.com.
Si vous ne pouvez pas obtenir d'informations sur la liste de diffusion, une de vos options est de prendre un contrat de support auprès de MySQL AB, qui vous donnera un contact direct avec les développeurs MySQL. See section 1.4.1 Support proposé par MySQL AB.
Le tableau suivant présente diverses autres listes de diffusions consacrée à MySQL, dans d'autres langues que l'anglais. Notez que ces ressources ne sont pas gérées par MySQL AB, ce qui fait que nous ne pouvons pas garantir leur qualité.
mysql-france-subscribe@yahoogroups.com Une liste de diffusion française
list@tinc.net Une liste de diffusion coréenne
subscribe mysql your@e-mail.address.
mysql-de-request@lists.4t2.com Une liste de diffusion allemande
subscribe mysql-de your@e-mail.address.
Vous aurez plus d'informations sur cette liste à http://www.4t2.com/mysql/.
mysql-br-request@listas.linkway.com.br Une liste de diffusion portugaise
subscribe mysql-br your@e-mail.address.
mysql-alta@elistas.net Une liste de diffusion espagnole
subscribe mysql your@e-mail.address.
Avant de soumettre un rapport de bogue ou une question, commencez par ces étapes simples :
Si vous n'arrivez pas à trouver une réponse à votre question dans le manuel ou dans les archives, vérifiez auprès de votre expert MySQL local. Si vous ne trouvez toujours pas la réponse, vous pouvez lire la section suivante et envoyer un mail bien préparé à mysql@lists.mysql.com.
Ecrire un bon rapport de bogue requiert de la patience, et le faire dès le début épargnera votre temps et le notre. Un bon rapport de bogue qui contient un cas de test complet améliorera vos chances de voir le bogue corrigé à la prochaine version. Cette section vous aidera à écrire correctement un rapport de bogue, de manière à ce que vous ne gaspillez pas votre temps à faire des textes qui ne nous aideront que peu ou pas.
Nous vous recommandons d'utiliser le script mysqlbug pour générer un
rapport de bogue (ou rapporter un problème), dans la mesure du possible. mysqlbug
est situé dans le dossier `scripts' de la distribution, ou, pour les distributions
binaire, dans le dossier `bin' du dossier d'installation de MySQL.
Si vous êtes dans l'incapacité d'utiliser mysqlbug, vous devez tout de même
inclure toutes les informations nécessaires listées dans cette section.
Le script mysqlbug vous aide à générer un rapport en déterminant automatiquement
les informations suivantes, mais si quelque chose d'important lui échappe, ajoutez
le dans votre message! Lisez cette section avec attention, et assurez vous que toutes
les informations décrites ici sont présentes dans votre message.
Pour rapporter un bogue ou un problème, il faut le soumettre à la liste
mysql@lists.mysql.com. Si vous pouvez rédiger un cas de
test qui démontre clairement le bogue, il faut le poster sur la liste
bugs@lists.mysql.com. Notez que sur cette liste, vous ne devez
poster qu'un rapport complet de bogue regénérable, avec le script
mysqlbug. Si vous travaillez sous Windows, vous devez ajouter
une description de votre système d'exploitation et de votre version
de MySQL. De préférence, il vaut mieux utiliser la dernière version de
MySQL, version stable ou de développement, avant d'envoyer un message.
Tout le monde doit être capable de reproduire le bogue en utilisant simplement
la ligne de commande ``mysql test < script'', avec le cas de bogue
fourni, ou bien d'exécuter un script shell ou Perl qui est inclut dans
le rapport de bogue. Tous les bogues postés sur
la liste bogues seront corrigés ou documentés dans la prochaine version
de MySQL. Si seul de petits changements sont nécessaires, nous publierons aussi
un patch.
Si vous avez découvert un problème de sécurité sensible dans MySQL, il faut envoyer un email à security@mysql.com.
Sachez qu'il est toujours possible de répondre à un message qui contient trop d'informations, alors qu'il est impossible de répondre à um message qui contient trop peu d'informations. Souvent, il est facile d'omettre des faits parce que vous pensez connaître la cause du problème et supposez que ces détails ne sont pas importants. Un bon principe à suivre est : si vous avez un doute à propos de quelque chose, faites nous en part. Il est bien plus rapide et bien moins frustrant d'écrire quelques lignes de plus dans un rapport plutôt que d'être obligé de demander une nouvelle fois et d'attendre une réponse parce que vous avez oublié une partie des informations la première fois.
L'erreur la plus commune est de ne pas indiquer le numéro de la version de MySQL qui est utilisé, ou de ne pas indiquer le système d'exploitation que vous utilisez (y compris le numéro de version de ce système d'exploitation). Ce sont des informations de première importance, et dans 99% d4es cas, le rapport de bogue est inutilisable sans ces informations. Souvent, nous recevons des questions telles que ``Pourquoi est ce que cela ne fonctionne pas pour moi?''. Puis nous nous aperçevons que la fonctionnalités en question n'est même pas programmée dans la version de MySQL utilisée, ou que le bogue décrit est déjà corrigé dans une nouvelle version de MySQL. Parfois aussi, les erreurs sont dépendantes des plate-formes. Dans ce cas, il est presque impossible de les corriger sans savoir quel système d'exploitation et quelle version exacte est utilisée.
Pensez aussi à fournir des informations concernant votre compilateur, si c'est pertinent. Souvent, les développeurs trouvent des bogues dans les compilateurs, et pensent que c'est liés à MySQL. La plupart des compilateurs sont en constant développement, et s'améliorent de version en version. Pour déterminer si votre problèe dépend de votre compilateur, nous avons besoin de savoir quel compilateur est utilisé. Notez que les problèmes de compilations sont des bogues, et doivent être traités avec un rapport de bogues.
Il est particulièrement utile de fournir une bonne description du bogue dans le rapport de bogue. Cela peut être un exemple de ce que vous avez fait qui a conduit au problème, ou une description précise. Les meilleurs rapports sont ceux qui incluent un exemple complet permettant de reproduire le bogue. See section D.1.6 Faire une batterie de tests lorsque vous faites face à un problème de table corrompue.
Si un programme produit un message d'erreur, il est très important d'inclure ce message dans votre rapport. Il est préférable que le message soit le message exact, car il est alors possible de le retrouver en utilisant les archives : même la casse doit être respectée. N'essayez jamais de vous rappeler d'un message d'erreur, mais faites plutôt un copier/coller du message complet dans votre rapport.
Si vous avez un problème avec MyODBC, essayez de générer un fichier de trace MyODBC. See section 8.3.7 Rapporter des problèmes avec MyODBC.
Pensez aussi que de nombreux personnes qui liront votre rapport
utilisent un formatage de 80 colonnes. Lorsque vous générez votre
rapport et vos exemples avec l'outil de ligne de commande, utilisez
une largeur de 80 colonnes. Utilisez l'option
--vertical (ou la fin de commande \G) pour les
affichages qui excèdent une telle largeur (par exemple,
avec la commande EXPLAIN SELECT; voyez l'exemple un peu
plus tard dans cette section.
Voici un pense-bête des informations à fournir dans votre rapport :
mysqladmin version. mysqladmin est
situé dans le dossier `bin' de votre distribution MySQL.
uname -a.
mysqld s'est arrété, il est recommandé d'inclure la requête qui a
mené à cet arrêt de mysqld. Vous pouvez généralement la trouver en
exécutant mysqld en ayant activé les logs. See section D.1.5 Utilisation des fichiers de log pour trouver d'où viennent les erreurs de mysqld.
mysqldump --no-data db_name tbl_name1 tbl_name2 ....
C'est très simple à faire, et c'est un moyen efficace d'obtenir un
descriptif de table, qui nous permettra de recrééer une situation
comparable à la votre.
SELECT, pensez à inclure le résultat de la commande
EXPLAIN SELECT ..., et au moins le nombre de ligne que la
commande SELECT doit produire. Vous devriez aussi inclure
le résultat de la commande SHOW CREATE TABLE table_name
pour chaque table impliquée. Plus vous nous fournirez d'informations,
plus nous aurons de chance de vous aider efficacement. Par exemple,
voici un excellent rapport de bogue (posté avec le script mysqlbug,
et effectivement rédigé en ANGLAIS) :
Exemple réalisé avec mysql en ligne de commande (notez l'utilisation
de la fin de commande \G, pour les résultats qui pourraient dépasser
les 80 colonnes de large) :
mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
<output from SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
<output from EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
<A short version of the output from SELECT,
including the time taken to run the query>
mysql> SHOW STATUS;
<output from SHOW STATUS>
mysqld, essayez
de fournir un script qui reproduit l'anomalie. Ce script doit inclure
tous les fichiers sources nécessaires. Plus votre script reproduira fidèlement
votre situation, le mieux ce sera. Si vous pouvez réaliser un cas de test
postez le sur la liste bugs@lists.mysql.com pour un traitement
en priorité!
Si vous ne pouvez pas fournir de script, fournissez tout au moins le
résultat de la commande mysqladmin variables extended-status processlist
dans votre mail pour fournir des informations sur les performances
de votre système.
mysqldump et créez un fichier `README' qui décrit votre
problème.
Créez une archive compressée de votre fichier en utilisant
tar et gzip ou zip, et placez le via ftp sur le
site de ftp://support.mysql.com/pub/mysql/secret/. Puis, envoyez
une courte description de votre problème à bugs@lists.mysql.com.
ftp pour les transférer
dans le dossier secret ftp://support.mysql.com/pub/mysql/secret/. Si
les données sont vraiment ultra secrètes et que vous ne souhaitez même
pas nous les montrer, alors utilisez d'autres noms et données pour votre
rapport, mais considérez cela comme un dernier recours.
mysqld,
et celle que vous utilisez avec les programmes comme mysqld et mysql,
et le script configure, qui sont souvent primordiaux et pertinents.
Ce n'est jamais une mauvaise idée que de les inclure. Si vous utilisez des
modules, comme Perl ou PHP, incluez aussi les versions de ces
logiciels.
mysqlaccess, celui de mysqladmin reload et
tous les messages d'erreurs que vous obtenez lors de la connexion. Lorsque
vous testez votre système de droits, il faut commencer par utiliser la
commande mysqladmin reload version et de vous connecter
avec le proramme qui vous pose problème. mysqlaccess est situé
dans le dossier `bin' de votre installation de MySQL.
parse error, vérifiez votre syntaxe
avec attention. Si vous ne pouvez rien y trouvez à redire, il est
très probable que votre version de MySQL ne supporte pas encore
cette fonctionnalité que vous essayez d'utiliser. Si vous utilisez la
version courante de mySQL et que le manuel
http://www.mysql.com/doc/ ne couvre pas la syntaxe que vous
utilisez, c'est que MySQL ne supporte pas votre syntaxe. Dans ce cas,
vos seules options sont d'implémenter vous même la syntaxe ou
d'envoyez un message à licensing@mysql.com pour proposer de
l'implémenter.
Si le manuel présente la syntaxe que vous utilisez, mais que vous avez une
ancienne version du serveur MySQL, il est recommandé de vérifier l'historique
d'évolution de MySQL pour savoir quand la syntaxe a été supportée. Dans ce
cas, vous avez l'option de mettre à jour votre MySQL avec une version
plus récente. See section C Historique des changements MySQL.
myisamchk ou les syntaxes SQL CHECK TABLE et
REPAIR TABLE. See section 4 Administration du serveur.
mysqld ne doit jamais corrompre une table
si il a été interrompu au milieur d'une mise à jour. Si vous pouvez
trouvez la cause de l'arrêt de mysqld, il est bien plus facile pour
nous de fournir un correctif.
See section A.1 Comment déterminer ce qui pose problème.
Si vous disposez de l'accès au support client, contactez aussi le support client à mysql-support@mysql.com, en plus de la liste de rapport de bogues, pour un traitement prioritaire.
Pour des informations sur les rapports de bogues avec MyODBC,
voyez section 8.3.4 Comment reporter les problèmes avec ODBC.
Pour des solutions aux problèmes les plus courants, voyez section A Problèmes et erreurs communes.
Lorsque des solutions vous sont envoyées individuellement et non pas à la liste, il est considéré comme bien vu de rassembler ces réponses et d'en envoyer un résumé sur le liste, de manière à ce que les autres en profitent aussi.
Si vous pensez que votre réponse peut avoir un intérêt général, vous pouvez envisager de l'envoyer sur la liste de diffusion, plutôt que de faire une réponse personnelle aux demandeurs. Essayez de rendre votre réponse aussi générale que possible, pour que suffisamment d'autres personnes puissent en profiter. Lorsque vous envoyez une réponse sur la liste, assurez vous qu'elle ne représente pas un doublon d'une réponse précédente.
Essayez de résumer l'essentiel de la question dans votre réponse. Ne vous croyez pas obligé de citer tout le message original.
Attention : n'envoyez pas de message avec le mode HTML activé ! De nombreux utilisateurs ne lisent pas leurs emails avec un navigateur.
En plus des différentes listes de diffusion MySQL, vous pouvez rencontrer
des utilisateurs expérimentés sur IRC (Internet Relay Chat).
Voici les meilleurs canaux, à notre connaissance :
#mysql
Principalement, des questions sur MySQL, mais les autres bases de données
et le langage SQL sont aussi acceptés.
#mysqlphp
Des questions à propos de MySQL et PHP, une combinaison populaire.
#mysqlperl
Des question sur MySQL et Perl, une autre combinaison populaire.
#mysql
Questions sur MySQL.
Si vous recherchez un client IRC pour vous connecter à un réseau IRC,
voyez donc X-Chat (http://www.xchat.org/).
X-Chat est disponible sous Unix et sous Windows.
Cette section présente comment MySQL interprète les standards SQL ANSI. Le serveur MySQL dispose de nombreuses extensions au standard ANSI et vous trouverez ici comment les exploiter. Vous trouvrez aussi des informations sur les fonctionnalités manquantes de MySQL et comment y trouver des palliatifs.
Notre but n'est pas, sans une bonne raison, de restreindre les capacités de MySQL à un usage unique. Même si nous n'avons pas les ressources de développement à consacrer à toutes les opportunités, nous sommes toujours interessés et prêts à aider ceux qui utilisent MySQL dans de nouveaux domaines.
Un de nos objectifs avec ce produit est de tendre à la compatibilité
ANSI 99, mais sans sacrifier la vitesse ou la robustesse. Nous ne
reculons pas devant l'ajout de nouvelle fonctionnalités au langage
SQL, ou le support de fonctionnalités hors SQL, qui améliorent
le confort d'utilisation de MySQL. La nouvelle interface de gestionnaires
HANDLER de MySQL 4.0 est un exemple de cette stratégie.
See section 6.4.2 Syntaxe de HANDLER.)
Nous continuons de supporter les bases transactionnelles et non transactionnelles pour combler les besoins des sites web ou des applications à fort besoin d'archivage, ainsi que les applications critiques à très haute disponibilité.
Le serveur MySQL a été conçu pour travailler avec des bases de taille moyenne (de 10 à 100 millions de lignes, ou des tables de 100 Mo) sur des systèmes de petite taille. Nous continuons d'améliorer MySQL pour qu'il fonctionne avec des bases gigantesques (tera octets), tout en conservant la possibilité de compiler une version réduite de MySQL pour qu'il fonctionne sur des appareils embarqués ou nomades. L'architecture compacte de MySQL rend possible le support de ces applications si différentes, sans aucun conflit dans les sources.
Nous n'étudions pas le support du temps réel ou des bases de données en grappe (même si vous pouvez dores et déjà réaliser de nombreuses applications avec les services de réplication).
Nous ne croyons pas au support natif du XML en base, mais nous allons faire en sorte d'ajouter le support XML que réclame nos clients du coté client. Nous pensons qu'il est préférable de conserver le serveur central aussi ``simple et efficace'' que possible, et développer les librairies qui gèrent la complexité du coté client. Cela fait partie de la stratégie que nous avons mentionné plus tôt, pour ne sacrifier ni la vitesse, ni la robustesse du serveur.
SQL92, niveau de base. ODBC niveau 0-3.51.
Nous nous dirigeons vers le support complet du standard ANSI SQL99, mais sans aucune concession sur la vitesse ou la qualité du code.
Si vous démarrez mysqld avec l'option --ansi, les comportements
suivants du serveurs MySQL changent :
|| devient l'opérateur de concaténation de chaîne, et non pas
l'opérateur binaire OR.
REAL est synonyme de FLOAT au lieu d'être synonyme de
DOUBLE.
SERIALIZABLE.
See section 6.7.3 Syntaxe de SET TRANSACTION.
Ceci revient à utiliser les options suivantes :
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
IGNORE_SPACE,SERIALIZE,ONLY_FULL_GROUP_BY.
Le serveur MySQL inclut des extensions que vous ne trouverez probablement
pas dans les autres bases de données. Soyez prévenus que si vous les
utilisez, votre code ne sera probablement pas portable sur d'autres serveurs
SQL. Dans certains cas, vous pouvez écrire du code qui inclut des spécificités
de MySQL, mais qui restent portables, en les incluant dans des
commentaires de la forme /*! ... */. Dans ce cas, le serveur MySQL va
analyser la chaîne et exécuter le code à l'intérieur de ces commentaires
comme une commande normale, mais d'autres serveurs ignoreront ces commentaires.
Par exemple :
SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...
Si vous ajoutez le numéro de version après le point d'exclamation '!',
la syntaxe sera exécutée uniquement si la version du serveur MySQL est
égale ou plus récente que le numéro de version utilisé.
CREATE /*!32302 TEMPORARY */ TABLE t (a int);
Cela signifie que si vous avez la version 3.23.02 ou plus récente,
le serveur MySQL va utiliser le mot réservé TEMPORARY.
Voici une liste des apports spécifiques de MySQL :
MEDIUMINT, SET, ENUM et
les types BLOB et TEXT.
AUTO_INCREMENT, BINARY, NULL,
UNSIGNED et ZEROFILL.
BINARY ou utiliser l'opérateur
BINARY pour forcer les comparaisons à prendre en compte la
casse, en fonction du jeu de caractères utilisé sur l'hôte du serveur
MySQL.
db_name.tbl_name.
Certains serveurs SQL fournissent la même fonctionnalité, mais
l'appellent un User space. Le serveur MySQL ne supporte par les
espaces de nom de tables, comme dans :
create table ralph.my_table...IN my_tablespace.
LIKE est possible avec des colonnes numériques.
INTO OUTFILE et STRAIGHT_JOIN dans les requêtes
SELECT. See section 6.4.1 Syntaxe de SELECT.
SQL_SMALL_RESULT de la commande SELECT.
EXPLAIN SELECT pour avoir le détail des
jointures de tables.
INDEX or KEY dans
une commande de création de table CREATE TABLE.
See section 6.5.3 Syntaxe de CREATE TABLE.
TEMPORARY et IF NOT EXISTS
avec CREATE TABLE.
COUNT(DISTINCT list) où list contient
plus d'un élément.
CHANGE col_name, DROP col_name ou
DROP INDEX, IGNORE ou RENAME dans une commande
ALTER TABLE. See section 6.5.4 Syntaxe de ALTER TABLE.
RENAME TABLE. See section 6.5.5 Syntaxe de RENAME TABLE.
ADD, ALTER, DROP et CHANGE
dans les clauses de la commande ALTER TABLE.
DROP TABLE avec les mots-clés IF EXISTS.
DROP TABLE.
LIMIT de la commande DELETE.
DELAYED des commandes INSERT et REPLACE.
LOW_PRIORITY des commandes INSERT, REPLACE,
DELETE et UPDATE.
LOAD DATA INFILE. Dans de nombreuses situations,
cette syntaxe est compatible avec la commande d'Oracle
LOAD DATA INFILE. See section 6.4.9 Syntaxe de LOAD DATA INFILE.
ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE et
REPAIR TABLE.
SHOW.
See section 4.5.6 Syntaxe de SHOW.
SET. See section 5.5.6 Syntaxe de SET.
GROUP BY. Cela donne de meilleures
performances pour certaines situations spécifiques, mais classiques.
See section 6.3.7 Fonctions avec la clause GROUP BY.
ASC ou DESC dans la clause GROUP BY.
|| et && comme
opérateurs logiques OR et AND, comme en langage C. Pour le serveur MySQL,
les opérateurs || et OR sont synonymes, ainsi que && et AND.
En conséquence, MySQL ne supporte pas l'opérateur de concaténation de chaînes
ANSI SQL ||. Utilisez plutôt la fonction CONCAT(). Comme
CONCAT() prend un nombre illimité d'arguments, il est facile de
convertir des expressions utilisant ||, pour qu'elles fonctionnent
sur le serveur MySQL.
CREATE DATABASE et DROP DATABASE.
See section 6.5.1 Syntaxe de CREATE DATABASE.
% est synonyme de MOD(). C'est à dire que
N % M est équivalent à MOD(N,M). % est supporté
pour les programmeurs C, et pour la compatibilité avec PostgreSQL.
=, <>, <= ,<, >=,>,
<<, >>, <=>, AND, OR ou LIKE
peuvent être utilisés pour les comparaisons de colonnes à gauche
de la clause FROM dans les commandes SELECT. Par exemple :
mysql> SELECT col1=1 AND col2=2 FROM tbl_name;
LAST_INSERT_ID().
See section 8.4.3.31 mysql_insert_id().
REGEXP et NOT REGEXP.
CONCAT() et CHAR() avec un argument ou plus de deux arguments.
Avec le serveur MySQL, ces fonctions peuvent prendre n'importe quel nombre
d'arguments.
BIT_COUNT(), CASE, ELT(),
FROM_DAYS(), FORMAT(), IF(), PASSWORD(),
ENCRYPT(), MD5(), ENCODE(), DECODE(),
PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS() et
WEEKDAY().
TRIM() pour réduire les chaînes. L'ANSI SQL
ne supporte que les suppressions de caractères uniques.
GROUP BY STD(),
BIT_OR() et BIT_AND().
REPLACE à la place de DELETE + INSERT.
See section 6.4.8 Syntaxe de REPLACE.
FLUSH, RESET et DO.
:= :
SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_table; SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
Nous tâchons de rendre le serveur MySQL compatible avec le standard ANSI SQL, et le standard ODBC SQL, mais dans certains cas, MySQL se comporte différemment.
VARCHAR, les espaces terminaux sont supprimés
lors du stockage de la valeur.
See section 1.8.5 Erreurs connues, et limitations de MySQL.
CHAR sont transformées automatiquement
en colonnes VARCHAR. See section 6.5.3.1 Modification automatique du type de colonnes.
REVOKE pour supprimer les droits d'un utilisateur sur une table.
See section 4.3.1 Syntaxe de GRANT et REVOKE.
NULL AND FALSE donnera la valeur NULL et non pas FALSE.
Nous pensons que dans cette situation, il n'est pas bon d'évaluer de nombreuses
conditions supplémentaires.
Pour voir la liste des priorités de développement des nouvelles extensions de MySQL, consultez la liste de tâches sur http://www.mysql.com/doc/en/TODO.html. C'est la toute dernière liste de tâche de ce manuel. See section 1.9 Les évolutions de MySQL (la liste des tâches).
SELECTs)Les sous-requtes ont ŽtŽ implŽmentŽes en MySQL 4.1. See section 1.6.1 Fonctionnalités disponibles depuis MySQL 4.1.
Jusqu'à la version 4.0, le serveur MySQL ne prenait en charge que les requêtes imbriquées de la forme
INSERT ... SELECT ... et REPLACE ... SELECT ....
Vous pouvez néanmoins utiliser la fonction IN() dans d'autres contextes.
Les sous-requêtes sont implémentées dans l'arborescence de développement 4.1.
En attendant, vous pourrez dans la plupart des cas réécrire la requête sans sous-requêtes :
SELECT * FROM table1 WHERE id IN (SELECT id FROM table2);
Ceci peut être réécrit de la façon suivante :
SELECT table1.* FROM table1,table2 WHERE table1.id=table2.id;
Les requêtes :
SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2);
SELECT * FROM table1 WHERE NOT EXISTS (SELECT id FROM table2
WHERE table1.id=table2.id);
peuvent être réécrites ainsi :
SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
WHERE table2.id IS NULL;
Pour des requêtes plus complexes, vous pouvez généralement créer des tables temporaires
contenant les sous-requêtes. Cependant, dans certains cas cette option ne fonctionnera
pas. Le cas le plus fréquent se produit avec les instructions
DELETE, pour lesquelles le SQL standard ne prend pas en charge les jointures
(sauf dans les sous Select). Dans une telle situation, en attendant que les sous-requêtes
soient prises en charge par MySQL Server, vous disposez de deux options.
La première option consiste à utiliser un langage de programmation procédural (tel que
Perl ou PHP) afin de soumettre une requête SELECT pour obtenir les clés primaires
des enregistrements à supprimer. On utilise ensuite ces valeurs pour construire
l'instruction DELETE (DELETE FROM ... WHERE ... IN (key1,key2, ...)).
La seconde option consiste à utiliser le SQL interactif pour construire automatiquement
un ensemble d'instructions DELETE, grâce à l'extension MySQL CONCAT()
(à la place de l'opérateur standard ||).
Par exemple :
SELECT CONCAT('DELETE FROM tab1 WHERE pkid = ', "'", tab1.pkid, "'", ';')
FROM tab1, tab2
WHERE tab1.col1 = tab2.col2;
Vous pouvez placer cette requête dans un fichier script et rediriger son entrée vers
l'interpréteur de ligne de commande mysql, tout en ouvrant un canal de communication
(pipe) pour diriger sa sortie vers une seconde instance de l'interpréteur :
shell> mysql --skip-column-names mydb < myscript.sql | mysql mydb
La version 4.0 de MySQL prend en charge les instructions DELETE sur plusieurs tables pouvant être
utilisées afin de supprimer efficacement des lignes à partir d'informations issues d'une table,
voire de plusieurs tables en même temps.
SELECT INTO TABLE
Le serveur MySQL ne supporte pas encore l'extension Oracle SQL :
SELECT ... INTO TABLE .... A la place, le serveur MySQL supporte
la syntaxe ANSI SQL INSERT INTO ... SELECT ..., qui revient au même.
See section 6.4.3.1 Syntaxe de INSERT ... SELECT.
INSERT INTO tblTemp2 (fldID) SELECT tblTemp1.fldOrder_ID
FROM tblTemp1 WHERE tblTemp1.fldOrder_ID > 100;
Vous pouvez aussi utiliser SELECT INTO OUTFILE... ou CREATE
TABLE ... SELECT.
Le serveur MySQL support les transactions avec les gestionnaires
de tables InnoDB et BDB. See section 7 Types de tables MySQL.
InnoDB dispose aussi de la compatibilité ACID.
Toutefois, les tables non transactionnelles de MySQL telles que
MyISAM exploitent un autre concept pour assurer l'intégrité
des données, appelé ``opérations atomiques''. Les opérations
atomiques disposent d'une bien meilleure protection des données pour
des performances également accrues. Comme MySQL supporte les deux
méthodes, l'utilisateur est capable de choisir celle qui correspond
à ses besoins, suivant qu'il a besoin de vitesse ou de sécurité.
Ce choix peut être fait table par table.
Comment exploiter les capacités de MySQL pour protéger l'intégrité des données, et comment ces fonctionnalités se comparent-elles avec les méthodes transactionnelles ?
ROLLBACK au lieu de COMMIT dans les situations
critiques, les transactions sont plus plus pratiques. Les transactions
s'assurent que les modifications non achevées ou les activités
corrosives ne sont pas archivées dans la base. Le serveur a l'opportunité
d'annuler automatiquement l'opération, et votre base de données
est sauve.
Le serveur MySQL, dans la plupart des cas, vous permet de résoudre
les problèmes potentiels en incluant de simples vérifications avant les
modifications, et en exécutant des scripts simples pour vérifier l'intégrité
de vos bases de données, ainsi que les incohérences, et pour réparer
automatiquement les problèmes, ou encore vous alerter si une erreur
est identifiée. Notez qu'en utilisant simplement le log de MySQL, ou
en utilisant un log supplémentaire, vous pouvez normalement réparer
à la perfection toutes les tables, sans aucune perte de données.
LOCK TABLES ou des modifications atomiques, qui
assurent que vous n'aurez jamais d'annulation automatique de la base,
ce qui est un problème commun des bases transactionnelles.
La méthode transactionnelle a ses avantages et ses inconvénients. De nombreux utilisateurs et développeurs d'applications dépendent de la facilité de pallier un problème lorsqu'une annulation semble nécessaire ou presque. Cependant, même si vous êtes néophyte des opérations atomiques, ou plus familier avec les transactions, prenez en considération le gain de vitesse que les tables non transactionnelles offrent. Ces gains vont de 3 a 5 fois la vitesse des tables transactionnelles les plus rapides et les mieux optimisées.
Dans des situations où l'intégrité est de la plus grande importance,
le serveur MySQL assure une intégrité du niveau des transactions,
ou encore mieux avec les tables non transactionnelles.
Si vous verrouillez les tables avec LOCK TABLES, toutes les
modifications seront bloquées jusqu'à ce que la vérification d'intégrité
soit faite (à comparer avec un verrou en écriture), les
lectures et insertions sont toujours possibles. Les nouvelles lignes
ne seront pas accessibles en lecture tant que le verrou n'aura pas
été levé. Avec INSERT DELAYED, vous pouvez faire attendre les
insertions dans une pile, jusqu'à ce que les verrous soit levés, sans que
le client n'attende cette levée de verrou. See section 6.4.4 Syntaxe de INSERT DELAYED.
``Atomique'', avec le sens que nous lui donnons, n'a rien de magique. Ce terme signifie simplement que vous pouvez être certain que lorsque vous modifiez des données dans une table, aucun autre utilisateur ne peut interférer avec votre opération, et qu'il n'y aura pas d'annulation automatique (ce qui pourrait arriver avec des tables transactionnelles si nous ne sommes pas trop soigneux). Le serveur MySQL garantit aussi qu'il n'y aura pas de lectures erronées.
Voici quelques techniques pour travailler avec des tables non transactionnelles :
LOCK TABLES, et vous n'avez nul
besoin de curseur lorsque vous modifiez des lignes à la volée.
ROLLBACK, vous pouvez adopter la
stratégie suivante :
LOCK TABLES ... pour verrouiller toutes les tables
que vous voulez utiliser.
UNLOCK TABLES pour libérer vos tables.
ROLLBACK possibles mais
pas certaines. La seule situation que ce cas ne prend pas en
compte est l'interruption du processus au milieu d'une mise à jour.
Dans ce cas, tous les verrous seront levés, mais certaines modifications
peuvent ne pas avoir été exécutées.
WHERE dans la commande UPDATE. Si la
ligne a été modifiée, nous indiquons au client : "Some of the data you have changed
has been changed by another user". En français : "certaines données que vous
voulez modifier ont été modifiées par un autre utilisateur". Puis nous
affichons l'ancienne ligne et la nouvelle ligne, pour laisser l'utilisateur
décider quelle version il veut utiliser.
Cela nous conduit à un résultat proche du verrouillage de ligne, mais en
fait, c'est bien mieux, car nous ne modifions que les colonnes qui en ont
besoin, en utilisant des valeurs relatives. Cela signifie qu'une commande
UPDATE typique ressemble à ceci :
UPDATE tablename SET pay_back=pay_back+'relative change';
UPDATE customer
SET
customer_date='current_date',
address='new address',
phone='new phone',
dette=dette+'emprunt'
WHERE
customer_id=id AND address='old address' AND phone='old phone';
Comme vous pouvez le voir, c'est très efficace, et fonctionne même si
un autre client a modifié la valeur pay_back ou dette.
ROLLBACK et/ou LOCK TABLES afin de gérer des
identifiant uniques pour certaines tables. Ils peuvent être gérés bien plus
efficacement en utilisant une colonne de type AUTO_INCREMENT,
en corrélation avec la fonction LAST_INSERT_ID() ou la fonction
C mysql_insert_id().
See section 8.4.3.31 mysql_insert_id().
Vous pouvez éviter le verrouillage de ligne. Certaines situations
le requièrent vraiment, mais elles sont rares. Les tables InnoDB
supportent le verrouillage de ligne. Avec les tables MyISAM, vous pouvez
utiliser une colonne de type flag, et faire ceci :
UPDATE tbl_name SET row_flag=1 WHERE id=ID;MySQL retournera 1 pour le nombre de lignes affectées si la ligne a été trouvée, car
row_flag ne vaut pas déjà 1 dans la ligne originale.
Vous pouvez comprendre la requête ci-dessus comme si le serveur MySQL avait utilisé
la commande suivante :
UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;
Une procédure stockée est une liste de commandes SQL qui peuvent être compilées et stockées sur le serveurs. Une fois que cela est fait, les clients n'ont pas besoin de soumettre à nouveau toute la commande, mais font simplement référence à la procédure stockée. Cela conduit à des performances bien meilleures, car les commandes n'ont pas à être analysées plusieurs fois, et que bien moins d'informations transitent sur le réseau. Vous pouvez aussi élevez le niveau conceptuel de votre application en mettant en place des librairies de fonctions sur le serveur.
Un trigger est une procédure stockée qui est activée lorsqu'un événement particulier survient. Par exemple, vous pouvez installer une procédure stockée qui est déclenchée dès qu'une ligne est effacée dans une table d'achat, pour que le client soit automatiquement effacé si tous ses achats sont effacés.
La future version du langage sera capable de supporter les procédures stockées. Notre objectif est d'impolémenter les procédures stockées pour la version 5.0 du serveur MySQL. Nous nous pencherons aussi sur les triggers.
Notez que les clés en SQL ne sont pas utilisées pour joindre des tables,
mais pour assurer l'intégrité référentielle (contraintes de clés
étrangères). Si vous voulez obtenir des résultats issus de tables multiples
avec une commande SELECT, vous allez joindre les tables comme ceci :
SELECT * FROM table1,table2 WHERE table1.id = table2.id;
See section 6.4.1.1 Syntaxe de JOIN. See section 3.5.6 Utiliser les clefs étrangères.
En MySQL version 3.23.44 et plus récentes, les tables InnoDB supportent
les vérifications d'intégrité référentielles. See section 7.5 Tables InnoDB. Pour les autres
types de tables, le serveur mySQL accepte la syntaxe FOREIGN KEY dans la
commande CREATE TABLE, mais ne la prend pas en compte.
La syntaxe FOREIGN KEY dans la clause ON DELETE ... est principalement
utilisée pour des raisons de documentation. Certaines applications ODBC
peuvent utiliser cette clause pour produire des conditions WHERE automatiques,
mais c'est généralement simple à éviter. FOREIGN KEY est parfois
utilisé pour vérifier une contrainte, mais cette vérification n'est pas
nécessaire en pratique, si les lignes sont insérées dans la table dans le
bon ordre.
Avec le serveur MySQL, vous pouvez contourner le problème de l'absence de la clause
ON DELETE ... en ajoutant la commande DELETE appropriée dans
l'application, lorsque vous effacez une ligne dans une table qui a une
clé étrangère. En pratique, cette technique est aussi rapide (et même
parfois plus rapide), et bien plus portable que l'utilisation des
clés étrangères.
Avec le serveur MySQL 4.0, vous pouvez utiliser les commandes d'effacement
multi-tables pour effacer des lignes dans plusieurs tables en une seule commande.
See section 6.4.6 Syntaxe de DELETE.
Dans un futur proche, nous allons étendre l'implémentation de la clause
FOREIGN KEY pour que cette information soit stockée dans le fichier
de spécification des tables et puisse être lu par mysqldump et ODBC.
Dans une étape ultérieure, nous allons implémenter les contraintes de clé
étrangère pour les applications qui ne peuvent pas être codées sans.
Gardez bien en tête que les clés étrangères sont souvent méconnues, ce qui peut causer de graves problèmes. Même lorsqu'elles sont utilisées correctement, ce n'est pas une solution magique pour les problèmes d'intégrité référentielle, même si cela simplifie parfois les choses.
Voici des avantages aux contraintes de clés étrangères :
Inconvénients :
Il est prévu d'implémenter les vues dans la version 5.0 du serveur MySQL.
Les vues sont la plupart du temps utiles pour donner accès aux utilisateurs à un ensemble de relations représentées par une table (en mode inaltérable). Beaucoup de bases de données SQL ne permettent pas de mettre à jour les lignes dans une vue, vous devez alors faire les mises à jour dans les tables séparées.
Vu que le serveur MySQL est la plupart du temps utilisé dans des applications où le développeur à un contrôle total sur l'utilisation de la base de données, la plupart de nos utilisateurs n'ont pas considéré les vues comme très importantes (du moins, personne n'a été assez intéressé à ce sujet pour être prêt à financer l'implémentation des vues).
On n'a pas forcément besoin des vues pour restreindre l'accès aux colonnes, et ce, parce que MySQL a un système de droits très sophistiqué. See section 4.2 Règles de sécurité et droits d'accès au serveur MySQL.
Certaines bases de données SQL utilisent `--' comme début de commentaire.
Le serveur MySQL utilise `#'. Vous pouvez
aussi utiliser la syntaxe du langage C /* ceci est un commentaire */.
See section 6.1.6 Syntaxe des commentaires.
MySQL version 3.23.3 et plus récent supporte les commentaires de type
`--', si ce commentaire est suivi d'un espace. Ceci est dû au fait
que ce type de commentaire a causé beaucoup de problèmes avec les
requêtes générées automatiquement, qui contiennent du code tel que
celui-ci, où nous insérons automatiquement la valeur du paiement
dans la table !payment! :
UPDATE tbl_name SET credit=credit-!payment!
Pensez à ce qui se passe lorsque la valeur de payment est négative.
Comme 1--1 est valide en SQL, la conséquence est de commencer
un commentaire `--'.
En utilisant notre implémentation des commentaires avec le serveur
MySQL version 3.23.3 et plus récent, 1-- ceci est un commentaire ne
pose pas ce type de problème.
Une autre fonctionnalité supplémentaire est que le client en ligne
de commande mysql supprime toutes les lignes qui commencent
par `--'.
Les informations suivantes sont destinées aux utilisateurs de MySQL avec des versions antérieures à la version 3.23.3 :
Si vous avez un programme SQL dans un fichier texte qui contient des commentaires au format `--', il est recommandé d'utiliser :
shell> replace " --" " #" < text-file-with-funny-comments.sql \
| mysql database
au lieu du classique :
shell> mysql database < text-file-with-funny-comments.sql
Vous pouvez aussi éditer le fichier de commande ``lui-même'' pour remplacer les commentaires `--' par des commentaires `#' :
shell> replace " --" " #" -- text-file-with-funny-comments.sql
Puis, rétablissez-les avec :
shell> replace " #" " --" -- text-file-with-funny-comments.sql
Les erreurs suivantes sont connues mais restent non corrigées en MySQL 3.23, car pour les corriger, il nous faudrait modifier trop de code : cela risquerait d'introduire des bugs bien pire. Ces bugs sont considérés comme 'non nuisibles' ou 'supportables'.
LOCK TABLE sur de multiples tables, puis, avec la même connexion,
faire un DROP TABLE sur l'une d'entre elle, alors qu'un autre
thread essai de verrouiller la table. Il est toutes fois possible d'utiliser
la commande KILL sur l'un des threads en question, pour résoudre ce
problème. Corrigé en 4.0.12.
SELECT MAX(key_column) FROM t1,t2,t3... où l'une des tables est vide
ne retourne aps NULL mais plutôt le valeur maximale de la colonne.
Corrigé en 4.0.11.
Les problèmes suivants sont connus, et sont en tête de liste pour être corrigés :
ANALYZE TABLE sur une table de type BDB, peut rendre la table inutilisable,
dans certains cas, jusqu'au prochain redémarrage de mysqld. Lorsque cela
survient, vous rencontrez les erreurs suivantes dans le fichier d'erreur
MySQL :
001207 22:07:56 bdb: log_flush: LSN past current end-of-log
ALTER TABLE sur une table BDB sur laquelle
vous avez exécuté des transactions à plusieurs commandes, jusqu'à ce que ces
transactions soient achevées : la transaction sera probablement ignorée.
ANALYZE TABLE, OPTIMIZE TABLE et REPAIR TABLE peuvent
causer des problèmes sur les tables avec lesquelles vous utilisez la
commande INSERT DELAYED.
LOCK TABLE ... et FLUSH TABLES ... ne vous
garantit pas qu'il n'y a pas une transaction en court sur
la table.
mysql pour accéder
à la base si vous n'utilisez pas l'option -A, ou si vous utilisez
la commande rehash. C'est particulièrement vrai si vous n'avez
pas de cache de table important.
Les problèmes suivants sont connus et seront corrigés en leur temps :
RPAD, ou de toute autre
fonction de chaîne qui peut ajouter des espaces à droite de la chaîne, dans une
requête qui utilise une table temporaire pour la résolution, alors toutes les
chaînes verront leurs espaces terminaux être supprimés. Voici un
exemple d'une telle requête :
SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, '
') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON
t1.record=t2.joinID ORDER BY t2.record;
Le résultat final de ceci est que vous ne pourres pas obtenir les
espaces à gauche dans ces chaînes.
Le comportement décrit ci-dessus existe dans toutes les versions de
MySQL.
La raison à cela est due au fait que les tables de type HEAP, qui sont
utilisées en premier comme table temporaires, ne sont pas capables
de gérer des colonnes de type VARCHAR.
Ce comportement sera corrigé dans l'une des versions de la série des 4.1.
CHAR(255))
dans les noms des tables, colonnes ou énumérations. Il est prévu de corriger
de problème dans les versions version 5.1, lorsque nous aurons établi
un nouveau format de définition des fichiers.
SET CHARACTER SET, il n'est pas
possible d'utiliser les caractères traduits dans les noms de bases,
de tables ou de colonnes.
_ ou % avec la commande
ESCAPE dans la clause LIKE... ESCAPE.
DECIMAL avec un nombre stocké dans un
autre format (+01.00, 1.00, 01.00), GROUP BY peut considérer ces
valeurs comme différentes.
DELETE FROM merge_table est utilisé sans la clause WHERE,
elle va simplement effacer le fichier de la table, et ne pas effacer les
tables associées.
BLOB ne peuvent pas être utilisées ``correctement'' dans
les clauses GROUP BY ou ORDER BY ou DISTINCT. Seuls, les
max_sort_length premiers octets (par défaut, 1024) seront utilisés
pour les comparaisons de BLOB. Ceci peut être modifié avec l'option
-O max_sort_length de mysqld. Un palliatif à ce problème est
d'utiliser une sous partie de chaîne :
SELECT DISTINCT LEFT(blob,2048) FROM tbl_name.
BIGINT ou DOUBLE (les deux
sont normalement de 64 bits). La précision dépend alors de la fonction
utilisée. La règle générale est que les fonctions de bits utilisent la
précision des BIGINT, IF et ELT() utilisent la
précision des BIGINT ou DOUBLE, et les autres utilisent
la précision des DOUBLE. Il faut donc éviter d'utiliser les
entiers non signés de grande taille, surtout s'ils dépassent la
taille de 63 bits (9223372036854775807) pour toute autre fonction que les
champs de bits ! La version 4.0 gère bien mieux les BIGINT que la 3.23.
BLOB et TEXT,
voient automatiquement leurs caractères blancs finaux supprimés. Pour le type
CHAR c'est correct, et c'est considéré comme une fonctionnalité par
la norme ANSI SQL92. Le hic est que pour le serveur MySQL les colonnes
VARCHAR sont traitées de la même façon.
ENUM et SET.
MIN(), MAX() et compagnie,
MySQL compare actuellement les colonnes de type ENUM et SET
par leur valeur de chaîne, plutôt que par leur position relative dans l'ensemble.
safe_mysqld redirige tous les messages de mysqld vers le log
mysqld. Le problème est que si vous exécutez
mysqladmin refresh pour fermer et ouvrir à nouveau l'historique,
stdout et stderr sont toujours redirigés vers l'ancien log.
Si vous utilisez --log extensivement, vous devriez éditer safe_mysqld
pour loger vers `'hostname'.err' au lieu de `'hostname'.log', de façon
à pouvoir facilement récupérer la place de l'ancien log, en effaçant les vieux,
et en exécutant mysqladmin refresh.
UPDATE, les colonnes sont modifiées de gauche à droite.
Si vous faite référence à une colonne modifiée, vous obtiendrez sa valeur modifiée,
plutôt que sa valeur originale. Par exemple :
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;Cette commande va modifier la colonne
KEY avec 2 au lieu de 1.
mysql> SELECT * FROM temporary_table, temporary_table AS t2;
RENAME ne fonctionne pas avec les tables TEMPORARY, ou les tables
utilisées dans un rassemblement (MERGE).
DISTINCT différemment si vous utilisez
des colonnes cachées dans une jointure. Dans une jointure, les colonnes
cachées sont comptées comme une partie du résultat (même si elles ne sont
pas montrées), tandis que dans les requêtes normales, les colonnes cachées
ne participent pas aux DISTINCT. Nous allons probablement modifier
ceci dans le futur, pour ne jamais exploiter les colonnes cachées avec
DISTINCT.
Voici un exemple :
SELECT DISTINCT mp3id FROM band_downloads
WHERE userid = 9 ORDER BY id DESC;
et
SELECT DISTINCT band_downloads.mp3id
FROM band_downloads,band_mp3
WHERE band_downloads.userid = 9
AND band_mp3.id = band_downloads.mp3id
ORDER BY band_downloads.id DESC;
Dans le second cas, MySQL 3.23.x pourrait vous donner deux lignes
identiques dans le résultat (car les lignes cachées id
diffèrent).
Notez que cela n'arrive que pour les requêtes où vous n'avez pas
de colonnes de la clause ORDER BY dans le résultat, ce que vous ne
pourriez pas faire en ANSI SQL.
rollback,
certains comportements sont différents avec MySQL d'avec d'autres serveurs
SQL. C'est nécessaire pour s'assurer que MySQL n'a jamais besoin d'annuler
une commande SQL. Cela peut sembler un peu étrange au moment ou les colonnes
doivent être vérifiées par l'application, mais cela vous fournit une
accélération notable, à cause d'optimisations qui ne pourraient pas avoir
lieu ailleurs.
Si vous donnez une valeur incorrecte à une colonne, MySQL va stocker
le meilleur code possible dans la colonne, au lieu d'annuler la
transaction :
NULL dans une colonne qui
n'accepte pas la valeur NULL, le serveur MySQL va stocker 0 ou ''
(chaîne vide) à la place : ce comportement peut être modifié avec l'option
de compilation -DDONT_USE_DEFAULT_FIELDS).
DATE et
DATETIME (comme 2000-02-31 ou 2000-02-00). L'idée est que ce n'est pas
au serveur SQL de faire le travail de validation. Si MySQL peut stocker
une date, et relire exactement cette date, alors MySQL va stocker cette
date. Si la date est totalement fausse (hors de l'intervalle de validité
du serveur), la valeur spéciale 0000-00-00 sera utilisée.
ENUM,
la valeur stockée sera la chaîne vide, de valeur numérique 0.
SET,
la valeur sera ignorée.
PROCEDURE sur une requête qui retourne un résultat vide,
dans certains cas, PROCEDURE ne transformera pas les colonnes.
MERGE ne vérifie pas si les tables
sous-jacentes sont de type compatible.
NaN, -Inf
et Inf pour les doubles. Utiliser ces valeurs générera des problèmes
lorsque vous essayerez d'exporter et d'importer des données. Comme solution
temporaire, vous pouvez remplacer NaN par
NULL (si possible) et -Inf et Inf par les
valeurs maximales possibles des colonnes double.
LIMIT sont traitées comme des valeurs
positives.
ALTER TABLE pour ajouter un index de type UNIQUE
à un table utilisée dans un rassemblement de tables MERGE, puis que
vous utilisez ALTER TABLE pour ajouter un index normal à la table
MERGE, l'ordre des clés sera différent pour les tables s'il y avait déjà
une ancienne clé qui n'était pas unique. Ceci est dû au fait que
ALTER TABLE place les clés UNIQUE avant les clés normales,
pour être capable de détecter les clés doublons plus vite.
Les bogues suivants sont connus dans les anciennes versions de MySQL :
DROP TABLE sur
une table qui fait partie des tables verrouillées par LOCK TABLES.
LOCK table avec WRITE.
FLUSH TABLES.
UPDATE qui
modifiait une clé avec la clause WHERE sur la même clé, pouvait
échouer car la même clé était utilisée pour rechercher les lignes et
la même ligne pouvait être trouvée plusieurs fois :
UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;Un palliatif est :
mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;Cela fonctionnera, car MySQL ne va pas utiliser d'index sur une expression dans la clause
WHERE.
Pour les bogues spécifiques aux systèmes d'exploitation, voyez la section sur la compilation et le port.
Cette section liste les fonctionnalités que nous prévoyons d'ajouter à MySQL.
La liste est grossièrement réalisée dans l'ordre de priorité. Si vous voulez modifier cet ordre, achetez une licence de support, et dites-nous ce que vous souhaitez voir en premier. See section 1.4 Support MySQL et licences.
L'objectif est de supporter complètement la norme ANSI SQL99, tout en lui ajoutant de nombreuses améliorations. Le défi est de faire tout cela sans sacrifier la vitesse d'exécution, ni la qualité du code.
Les fonctionnalités suivantes ne sont pas encore en MySQL 4.1, mais il est prévu de les implémenter avant que MySQL 4.1 passe en version beta. Pour une liste des fonctionnalités déjà disponibles en MySQL 4.1, voyez section 1.6.1 Fonctionnalités disponibles depuis MySQL 4.1.
ROLLUP OLAP (Online Analytical Processing)
pour les applications d'entrepôt de données.
Le développement des nouvelles fonctionnalités est passé en version 5.0.
Les fonctionnalités suivantes sont prévues pour la version 5.0. Notez que comme nous avons de nombreux développeurs qui travaillent sur différents projets, il peut aussi y avoir des ajouts de fonctionnalités. Il y a aussi des chances que ces fonctionnalités soient ajoutées en MySQL 4.1. Pour une liste des fonctionnalités déjà disponibles en MySQL 4.1, voyez section 1.6.1 Fonctionnalités disponibles depuis MySQL 4.1.
VARCHAR (ce support est déjà disponible
avec le format de table MyISAM).
SHOW COLUMNS FROM table_name (utilisé par le client mysql
pour permettre la recherche de nom de colonnes) ne devrait pas ouvrir
la table, mais seulement le fichier de définition. Cela prendra moins
de mémoire, et sera bien plus rapide.
DELETE sur les tables MyISAM l'utilisation
des caches de lignes. Pour cela, nous devons modifier le thread de cache
de ligne lorsque nous modifions le fichier `.MYD'.
HEAP :
SET CHARACTER SET, nous devrions traduire toute la
requête en un coup, et non par chaînes. Cela permettra aux utilisateurs
d'exploiter des caractères traduits dans les noms de base, table et colonne.
RENAME TABLE, utilisé sur une table active dans
un MERGE, qui conduit à la corruption de la table.
FOREIGN KEY supporte tous les types de tables.
BIT pour qu'il prenne 1 bit (actuellement, BIT
prend 1 caractère).
RENAME DATABASE. Pour que cela soit sécuritaire
pour tous les pilotes de stockage, cela doit fonctionner comme ceci :
RENAME.
CONNECT BY PRIOR ..., inspirée d'Oracle, pour traiter
les structures de type arbre (hiérarchical).
SUM(DISTINCT).
INSERT SQL_CONCURRENT et mysqld --concurrent-insert pour faire
des insertions concurrents à la fin du fichier, même si il est verrouillé
en lecture.
UPDATE.
Par exemple :
UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c.
GROUP BY,
comme ceci :
SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY id.
IMAGE à la commande LOAD DATA INFILE
pour ne pas modifier les champs TIMESTAMP et AUTO_INCREMENT.
LOAD DATE INFILE ... UPDATE.
LOAD DATA INFILE ... REPLACE INTO.
LOAD DATA INFILE utilisable comme ceci :
LOAD DATA INFILE 'file_name.txt' INTO TABLE tbl_name
TEXT_FIELDS (text_field1, text_field2, text_field3)
SET table_field1=CONCAT(text_field1, text_field2),
table_field3=23
IGNORE text_field3
Cela peut être utilisé pour ignorer des colonnes supplémentaires dans le fichier texte,
ou pour modifier des colonnes en fonction de données dans les valeurs entrantes.
LOAD DATA INFILE 'file_name' INTO TABLE 'table_name' ERRORS TO err_table_name.
Cela va faire que les erreurs et alertes ne seront pas enregistrées dans
la table err_table_name. Cette table a la strucutre suivante :
line_number - numéro de ligne dans le fichier texte error_message - message d'alerte ou d'erreur et peut être data_line - le numéro de ligne dans le fichier de données
SET :
ADD_TO_SET(value,set)
REMOVE_FROM_SET(value,set)
t1 JOIN t2 ON ... et t1 JOIN t2 USING ...
Actuellement, nous ne pouvons utiliser cette syntaxe qu'avec LEFT JOIN.
mysql au beau milieu d'une requête, vous
pouvez ouvrir une autre connexion pour tuer la requête en cours.
Ou bien, une tentative doit être faite pour détecter cela sur le serveur.
SHOW INFO FROM tbl_name doit être implémenté pour connaitre les
informations de bases des tables.
SELECT a FROM crash_me LEFT JOIN crash_me2 USING (a);
dans ce cas, a est supposé provenir de la table crash_me.
DELETE et REPLACE dans les commandes UPDATE
(cela va effacer les lignes lors d'un doublon dans la requête).
DATETIME pour stocker les fractions de secondes.
DEFAULT) pour les colonnes.
Indiquer une erreur lors des commandes INSERT, si elle contient une
colonne qui n'a pas de valeur par défaut.
ANY(), EVERY() et SOME().
En ANSI SQL, elles ne fonctionnent que sur les colonnes de type booléens, mais
nous pouvons étendre leur champ d,action aux colonnes et expression, en
appliquant la règle suivante : value == 0 -> FALSE et
value <> 0 -> TRUE.
MAX(column) ait le mêm type de colonne :
mysql> CREATE TABLE t1 (a DATE); mysql> INSERT INTO t1 VALUES (NOW()); mysql> CREATE TABLE t2 SELECT MAX(a) FROM t1; mysql> SHOW COLUMNS FROM t2;
INSERT ... SELECT pour utiliser optionnellement des insertions
simultanées.
pread()/pwrite() sur Windows
pour permettre les insertions concurrentes.
SELECT MIN(column) ... GROUP BY.
long_query_time avec une granularité
de l'ordre de la micro seconde.
myisampack dans le serveur, activer les commandes PACK et
COMPRESS depuis le serveur.
INSERT/DELETE/UPDATE pour que nous puissions nous rétablir
si jamais le fichier d'index est plein.
ALTER TABLE sur une table qui est
un lien symbolique sur un autre disque, les tables tempooraires seront
aussi faites sur ce disque.
DATE/DATETIME qui gère les fuseaux horaire correctement,
pour résoudre le problème du décalage horaire.
MyISAM) sans les threads.
LIMIT, comme par exemple
LIMIT @a,@b.
mysql vers un serveur web.
LOCK DATABASES (avec différentes options).
SHOW STATUS. Les lignes
lues et modifiées. Les sélections sur tables uniques et les jointures.
Le nombre moyen de tables dans une sélection. Le nombre de rquêtes
ORDER BY et GROUP BY.
mysqladmin copy database new-database; a besoin de la commande COPY
dans mysqld.
SHOW HOSTS affichera les informatiosn concernant le cache de noms d'hôtes.
NULL pour les colonnes calculées.
Item_copy_string sur les valeurs numériques,
pour éviter les conversions nombre -> chaîne -> nombre en cas de :
SELECT COUNT(*)*(id+0) FROM table_name GROUP BY id
ALTER TABLE pour qu'il n'interrompe pas le client
qui exécute des INSERT DELAYED.
UPDATE,
elles contiennent les anciennes valeurs d'avant la modification.
get_changed_tables(timeout,table1,table2,...).
SET TIMESTAMP=#;.
MINUS, INTERSECT et FULL OUTER JOIN.
(actuellement, UNION [en 4.0] et LEFT OUTER JOIN fonctionnent).
SQL_OPTION MAX_SELECT_TIME=# pour donner une limite de temps à une requête.
LIMIT pour permettre la lecture de données à la fin du résultat.
safe_mysqld : selon la FSSTND (que
Debian essaie de suivre) les fichiers PID devraient être placés dans
`/var/run/<progname>.pid' et les fichiers de logs dans `/var/log'.
Il serait bien si vous pouviez mettre le "DATADIR" dans la première
déclaration de "pidfile" et "log", de façon à ce que l'emplacement
de ces fichiers puisse être modifié en une seule ligne.
zlib() pour les fichiers gzip, avec la
commande LOAD DATA INFILE.
BLOB (en partie résolu).
AUTO_INCREMENT lorsque l'on utilise
la valeur 0. Utilisez NULL à la place.
JOIN avec parenthèses.
GET_LOCK. Lors de ces verrous
multiples, gérer le cas des blocages par verrous qui pourrait être introduit.
Le temps est indiqué en temps de travail et non pas en temps normal.
Nos utilisateurs ont réussi à exécuter nos tests avec un grand nombre
de serveurs SQL Open Source ou non. Nous connaissons des
tests exécutés avec Oracle, DB/2,
Microsoft SQL Server et d'autres produits commerciaux.
Pour des raisons légales, nous ne pouvons pas les publier dans notre
manuel de référence.
Cette section inclut la comparaison de MySQL avec mSQL pour des
raisons historiques, et avec PostgreSQL car c'est aussi une base
Open Source. Si vous avez des résultats de tests que nous pouvons
publier, contactez-nous à benchmarks@mysql.com.
Pour une liste comparative des fonctions et types supportés, voyez la
page web de l'utilitaire crash-me à l'adresse
http://www.mysql.com/information/crash-me.php.
MySQL face à mSQLMySQL. See section 5.1.4 La suite de tests MySQL.
Comme il n'y a pas de création de threads, que l'analyseur est plus
petit, et que les fonctionnalités sont moins nombreuses,
mSQL devrait être plus rapide avec :
INSERT dans des tables très simples, avec peu
de colonnes et d'index.
CREATE TABLE et DROP TABLE.
SELECT sur tout ce qui n'est pas indexé (une analyse
de table est très facile).
MySQL devrait être bien plus rapide.
D'un autre coté, le serveur MySQL est plus rapide que mSQL (et
que les autres serveurs SQL) avec :
SELECT complexes.
MySQL a un protocole plus rapide,
plus sûr et bien meilleur).
MySQL a une gestion plus
efficace et utilise les colonnes VARCHAR indexées.
SELECT avec de nombreuses expressions.
SELECT sur de grandes tables.
MySQL
est complètement multi-threadé. Chaque connexion possède son propre
thread, ce qui signifie qu'il y a pas d'attente entre les threads
(à moins que l'un d'entre eux modifie une table que l'autre veut
utiliser). En mSQL, une fois que la connexion a été établie,
les autres doivent attendre que la première ait fini, indépendamment
de la durée d'exécution de la requête. Lorsque la première connexion
se termine, le suivant peut être servi, tandis que les autres
attendent.
mSQL peut devenir irrémédiablement lent si vous modifiez
l'ordre des tables dans la colonne SELECT. Dans la suite de test,
il s'est vu des tests 15000 fois plus lent que MySQL. Ceci est dû au
manque d'optimiseurs chez mSQL.
Toutefois, si vous avez placé les tables dans le bon ordre avec
mSQL2 et que la clause WHERE est simple et utilise les
index, la jointure peut être plutôt rapide.
See section 5.1.4 La suite de tests MySQL.
ORDER BY et GROUP BY.
DISTINCT.
TEXT et BLOB.
GROUP BY et HAVING.
mSQL ne supporte pas du tout la clause GROUP BY.
MySQL supporte totalement la clause GROUP BY avec les clauses
HAVING et les fonctions suivantes : COUNT(), AVG(), MIN(),
MAX(), SUM() et STD(). COUNT(*) est
optimisée pour retourner très vite le résultat si SELECT lit les
lignes dans une table, qu'aucune autre colonne n'est lue, et qu'il n'y
a pas de clause WHERE. MIN() et MAX() accepte les chaînes
de caractères comme arguments.
INSERT et UPDATE avec calculs d'expression.
MySQL peut faire des calculs d'expression dans les commandes INSERT et
UPDATE. Par exemple :
mysql> UPDATE SET x=x*10+y WHERE x<20;
MySQL supporte les alias de colonne.
MySQL, si un nom de colonne est unique dans les tables utilisées pour
une jointure, vous n'avez pas à utiliser son identifiant total.
SELECT avec des fonctions
MySQL dispose de nombreuses fonctions (trop nombreuses à lister ici : voir section 6.3 Fonctions à utiliser dans les clauses SELECT et WHERE).
MySQL a des types très précis, et vous pouvez créer des tables avec un
très petit espace. Un exemple de type de données pratique est le
type MEDIUMINT qui occupe 3 octets. Si vous avez 100 millions
d'enregistrement, économiser un octet par enregistrement est très
important.
mSQL2 a un jeu de type de données plus limité, ses tables sont donc
plus grosses.
MySQL, voyez section 1.2.3 Jusqu'à quel point MySQL est il stable ?.
Nous n'avons aucune expérience avec la stabilité du code de mSQL, alors
nous ne nous prononceront pas la-dessus.
MySQL dispose d'une licence
plus souple que mSQL, est il est aussi moins cher que
mSQL. Quelque soit le produit que vous utilisez, n'oubliez pas
de prendre un contrat de support par email ou une licence commerciale.
MySQL a la même interface avec Perl que mSQL, avec des
fonctionnalités supplémentaires.
MySQL supporte de nombreux pilotes JDBC :
MySQL Connector/J est un pilote natif Java.
La version 3.x est publiŽe sous une licence double (GPL et commerciale).
gwe : une interface Java par GWE technologies (non supporté).
jms : un pilote gwe amélioré par Xiaokun Kelvin ZHU
X.Zhu@brad.ac.uk (non supporté).
twz : un pilote JDBC de type 4, écrit par Terrence W. Zellers
zellert@voicenet.com. Il est commercialisé, mais gratuit pour
les utilisations personnelles et dans le cadre des études (non supporté).
mSQL a un pilote JDBC, mais nous n'avons pas l'expérience
pour le comparer.
MySQL a une petite équipe de développeur, mais nous sommes très
habitués à coder en C et C++, très rapidement. Comme les
threads, les fonctions, GROUP BY et de nombreuses autres
fonctionnalités ne sont pas encore codées pour mSQL, il y a
beaucoup faire pour nous rattraper. Pour mesurer cela, vous pouvez
consulter le fichier d'historique de mSQL `HISTORY' pour l'an
dernier, et le comparer avec la section nouveautés du manuel de référence
MySQL (see section C Historique des changements MySQL). Il est alors assez évident de voir qui se développe
plus vite.
mSQL et MySQL ont des contributions de
tiers très intéressantes. Comme il est plus facile de porter vers les
versions plus récentes (depuis mSQL vers MySQL), presque toutes
les applications intéressantes de mSQL sont disponibles pour MySQL.
MySQL est livré avec un programme simple msql2mysql qui corrige les
différences de syntaxe entre mSQL et MySQL pour la plupart des
fonctions de l'API C.
Par exemple, il modifie les occurrences de msqlConnect() en
mysql_connect(). Convertir un programme client de mSQL vers
MySQL requiert un effort minimal.
mSQL pour MySQL
Selon notre expérience, il ne prend pas longtemps pour convertir des
outils tels que msql-tcl et msqljava qui utilisent
l'API C de mSQL pour qu'ils fonctionnent avec l'API C de MySQL.
La procédure de conversion est la suivante :
msql2mysql sur la source. Ce script requiert
le programme replace, qui est distribué avec le serveur MySQL.
Les différences entre l'API C de mSQL et de MySQL sont :
MYSQL comme type de connexion, alors
que mSQL utilise un int.
mysql_connect() prend un pointeur sur la structure MYSQL
comme paramètre. Il est facile d'en définir un globalement, ou
d'utiliser la fonction malloc() pour en obtenir un.
mysql_connect() prend aussi deux paramètres supplémentaires,
qui sont le nom de l'utilisateur et son mot de passe. Vous pouvez aussi
utiliser NULL, NULL pour retrouver l'utilisation classique.
mysql_error() prend la structure MYSQL comme paramètre.
Ajoutez simplement ce paramètre à votre vieux code msql_error(),
si vous portez du vieux code.
mSQL ne retourne que le texte d'erreur.
mSQL et de MySQLIl y a tellement de différences qu'il est impossible (ou tout au moins très difficile) de ne pas les supporter toutes.
Les traits les plus caractéristiques de différences entre le protocole
de communication de MySQL et de mSQL :
mSQL 2.0 et MySQLTypes de colonnes
Serveur MySQL
CREATE TABLE):
ENUM pour les chaînes à valeurs limitées.
SET pour les combinaisons de valeurs.
BIGINT pour les entiers 64-bit.
UNSIGNED pour les entiers et nombres à virgule flottante.
ZEROFILL pour les entiers.
AUTO_INCREMENT pour les colonnes qui sont PRIMARY KEY.
See section 8.4.3.31 mysql_insert_id().
DEFAULT pour toutes les colonnes.
mSQL2
mSQL correspondent aux types de MySQL dans cette table :
mSQL type | Type MySQL correspondant |
CHAR(len) | CHAR(len)
|
TEXT(len) | TEXT(len). len est la taille maximale.
Et LIKE fonctionne.
|
INT | INT. Avec de nombreuses options supplémentaires.
|
REAL | REAL. Ou FLOAT. Les versions 4 et 8 octets sont disponibles.
|
UINT | INT UNSIGNED
|
DATE | DATE. Utilise le format ANSI SQL plutôt que le format spécifique de mSQL.
|
TIME | TIME
|
MONEY | DECIMAL(12,2). Un nombre à virgule fixe.
|
Création d'index
Serveur MySQL
CREATE TABLE.
mSQL
CREATE INDEX séparée.
Insertion d'un identifiant unique dans une table
Serveur MySQL
AUTO_INCREMENT.
See section 8.4.3.31 mysql_insert_id().
mSQL
SEQUENCE dans la table et sélectionnez la colonne _seq.
Obtenir un identifiant unique pour une ligne
Serveur MySQL
PRIMARY KEY ou UNIQUE à la table et utilisez ceci.
Nouveau en version 3.23.11 : si la clé PRIMARY ou UNIQUE est constituée
d'une seule colonne et qu'il est de type entier, vous pouvez y faire référence
avec _rowid.
mSQL
_rowid. Notez bien que _rowid peut changer durant
ce temps, en fonction de nombreux facteurs.
Lire la date de dernière modification d'une colonne
Serveur MySQL
TIMESTAMP dans la table. Cette colonne
prend automatiquement la date et l'heure courante lors des commandes
INSERT ou UPDATE si vous ne lui affectez pas de valeur,
ou si vous lui donnez la valeur NULL.
mSQL
_timestamp.
Comparaisons avec la valeur NULL
Serveur MySQL
NULL
retourne toujours NULL.
mSQL
mSQL, NULL = NULL est vrai (TRUE). Vous devez
changer =NULL en IS NULL et <>NULL en
IS NOT NULL lorsque vous portez du vieux code de mSQL vers MySQL.
Comparaisons de chaînes
Serveur MySQL
BINARY, qui fera que les comparaisons peuvent être faites
en fonction de l'ordre ASCII utilisé sur l'hôte MySQL.
mSQL
Recherche insensible à la casse
Serveur MySQL
LIKE est un opérateur sensible ou non à la casse, suivant les
colonnes utilisées. Si possible, MySQL utilise des index si l'argument
de LIKE ne commence pas par un caractère joker.
mSQL
CLIKE.
Gestion des espaces finaux
Serveur MySQL
CHAR et
VARCHAR. Utilisez les colonnes de type TEXT si ce comportement
n'est pas souhaité.
mSQL
clause WHERE
Serveur MySQL
AND est calculé avant
les OR. Pour obtenir le comportement de mSQL avec MySQL, utilisez
les parenthèses (tel que présenté dans l'exemple un peu plus loin).
mSQL évalue les opérations de gauche à droite. Cela signifie que
mSQL suivant :
mysql> SELECT * FROM table WHERE a=1 AND b=2 OR a=3 AND b=4;Pour le passer sur MySQL et le faire fonctionner comme sur
mSQL,
vous devez ajouter ces parenthèses :
mysql> SELECT * FROM table WHERE (a=1 AND (b=2 OR (a=3 AND (b=4))));
Contrôle d'accès
Serveur MySQL
mSQL
PostgreSQLLorsque vous lirez ces sections, notez bien que les deux produits évoluent continuellement. Les équipes de MySQL AB et de PostGreSQL travaillent toutes deux à rendre leur base les meilleures possibles, et elles présentent toutes les deux des alternatives sérieuses aux bases de données commerciales.
La comparaison qui suit a été fait par MySQL AB. Nous avons essayé d'être aussi précis et objectifs que possible, mais même si nous connaissons MySQL sur le bout des doigts, nous n'avons pas une connaissance aussi pointues des possibilitées de PostgreSQL : nous pourrions être en erreur. Nous corrigerons ces erreurs dès qu'elles seront portées à notre attention.
Nous souhaitons noter que PostgreSQL et MySQL sont deux produits largement
répandus, mais qui présentent des objectifs différents, même si tous les
deux se dirigent vers la compatibilité ANSI SQL. Cela signifie que pour
certaines applications, MySQL est bien plus optimisé, et pour d'autres,
c'est PostGreSQL. Lorsque vous choisissez votre serveur de base de données,
commencez par vérifier que le jeu de fonctionnalités de votre base correspond
bien à votre application. Si vous avez besoin de vitesse pure, MySQL est
probablement votre choix. Si vous avez besoin des fonctionnalités que PostGreSQL
propose, utilisez PostgreSQL.
Lorsque nous ajoutons des fonctionnalités à MySQL, nous mettons un point d'honneur à le faire de manière optimale et définitive. Le code doit être tellement bon que vous n'y verrez rien à ajouter dans un futur accessible. Nous sommes peu enclins à sacrifier la vitesse aux fonctionnalités, mais nous faisons notre possible pour trouver une solution qui donnera le meilleur. Cela signifie que le développement prend plus de temps, mais que le résultat en vaut la peine. Ce type de développement n'est possible que parce que le code est vérifié par quelques (actuellement 2) personnes avant qu'il ne soit inclus dans le serveur.
Chez MySQL AB, nous croyons aux publications fréquentes car cela nous permet de transmettre nos nouveautés plus rapidement aux utilisateurs. Comme nous publions une nouvelle version mineure toutes les trois semaines, et une version majeure chaque année. Toutes les versions sont testées soigneusement, avec nos outils de tests et sur de nombreuses plate-formes.
PostgreSQL est basé sur un noyau de nombreux contributeurs. Avec cette configuration, il est logique d'ajouter de nombreuses fonctionnalités, au lieu de les implanter optimalement, car il sera toujours temps d'optimiser lorsque le besoin s'en fera sentir.
Une autre différence majeure entre MySQL et PostgreSQL est que presque tout le code de MySQL est fait par des développeurs employés par MySQL AB et qui travaillent toujours sur ce code. Les seules exceptions sont le moteur de transaction et la librairie d'expressions régulières.
Le contraste est saisissant avec le code de PostgreSQL, dont la majorité est réalisée par un grand groupe de personnes avec différentes sensibilités. Ce n'est que récemment que les développeurs de PostGreSQL ont annoncé qu'ils ont eu finalement le temps de faire le tour du code de la version courante.
Les deux stratégies de développement présentées ont leur mérites et inconvénients. Chez MySQL AB, nous pensons, bien sur, que notre modèle est le meilleur car il conduit à une meilleure cohérence du code, et, à notre avis, moins de bogues. Comme nous sommes les auteurs du serveur MySQL, nous sommes les mieux placés pour coordonner les publications.
Sur la page crash-me
(http://www.mysql.com/information/crash-me.php)
vous pouvez trouver une liste des avantages et limitations que
l'on peut détecter avec un programme. Notez bien que de nombreuses
évaluations numériques peuvent être modifiées avec les options
de démarrage des différentes bases de données. Cette page web est
extrêmement pratique si vous voulez vous assurer que votre application
fonctionnera sur différents serveurs SQL, ou si vous voulez
convertir votre application d'un serveur à l'autre.
MySQL offre les avantages suivants sur PostgreSQL:
MySQL est généralement plus rapide que PostgreSQL. MySQL
4.0.1 a aussi un cache de requêtes qui peut accélérer les requêtes
pour les lectures de tables les plus fréquentes.
Cygwin. Nous avons
entendu dire que PostgreSQL n'est pas encore stable sous Windows mais non n'avons
pas été capable de le vérifier nous-mêmes.
VACUUM une fois de temps en temps pour
récupérer l'espace vide issu des commandes UPDATE et DELETE,
et pour faire des analyses statistiques qui sont primordiales pour
obtenir de bonnes performances avec PostgreSQL. VACUUM est aussi
nécessaire après avoir ajouté un grand nombre de lignes dans une table.
Sur un système très occupé avec de nombreuses modifications,
VACUUM doit être exécuté très fréquemment, et parfois, plusieurs
fois dans la journée. Durant l'exécution de VACUUM, qui peut prendre
plusieurs heures si la base de données est importante, le serveur est,
d'un point de vue production, quasiment mort. Notez qu'avec
PostgreSQL version 7.2, l'entretien simple des tables ne nécessite plus
le verrouillage des tables, et le niveau d'utilisation est alors
à peu près normal. Une nouvelle commande
VACUUM FULL effectue les entretiens traditionnels en verrouillant
la table, et en réduisant sa taille sur le disque.
crash-me
(http://www.mysql.com/information/crash-me.php), ainsi que
la suite de performances. Le système de tests est souvent modifié avec
des nouveaux tests pour les nouvelles fonctionnalités, ainsi que les bogues
qui nous sont rapportés. Nous testons chacune de nos versions sur un
grand nombre de plate-formes. Ces tests sont plus sophistiqués que tout
ce que nous avons pu voir chez PostgreSQL, et il nous assurent que le serveur
MySQL reste de bonne qualité.
PostgreSQL.
ALTER TABLE beaucoup plus puissante.
HEAP, ou bien sur le disque, comme
les tables MyISAM. See section 7 Types de tables MySQL.
InnoDB et BerkeleyDB. Comme
chaque moteur de transactions travaille dans différentes conditions,
cela donne plus de possibilités aux auteurs d'applications pour choisir
leur solution optimale pour la configuration du serveur, au besoin
table par table. See section 7 Types de tables MySQL.
MERGE vous donnent un moyen d'accéder instantanément
a plusieurs tables de même structure, et de les utiliser ensemble, comme
une seule. C'est le moyen parfait lorsque vous avez des tables de logs
trop grosses, et que vous les séparez par mois.
See section 7.2 Tables assemblées MERGE.
myisampack, le générateur de tables MySQL compressées en lecture seule.
INSERT, SELECT et UPDATE/DELETE au niveau de l'utilisateur
pour une base ou une table, MySQL vous permet de définir un jeu
de droits complet pour une base, une table ou une colonne. MySQL
vous permet aussi de spécifier des droits par hôte ou utilisateur.
See section 4.3.1 Syntaxe de GRANT et REVOKE.
InnoDB) sont implémentés
avec des fichiers (une table par fichier), ce qui rend très souple
les sauvegardes, les déplacements et les effacements, ou même l'utilisation
des liens symboliques pour les tables et les bases, même lorsque le
serveur est éteint.
MyISAM (le
type de tables MySQL le plus courant). Un outil de réparation n'est nécessaire
que pour les corruptions physiques dans un fichier de données, et généralement,
pour corriger une défaillance du matériel. Elle permet à la majorité des données
d'être récupérées.
Les inconvénients de MySQL face à PostgreSQL:
MyISAM, est dans de nombreux cas plus rapide que les verrous de
page, de ligne ou le versionnage. L'inconvénient est que si l'on ne prend
pas garde au fonctionnement du verrouillage de table, une requête seule,
à longue durée d'exécution peut bloquer la table en écriture pour un
long moment. Cela peut être évité en concevant correctement l'application.
Sinon, on peut toujours changer le gestionnaire de la table pour un
modèle transactionnel. See section 5.3.2 Problème de verrouillage de tables.
UPDATE multi-tables, et en
MySQL version 4.1, avec les sous-sélections.
En MySQL version 4.0, on peut utiliser les effacements multi-tables pour
effacer plusieurs lignes dans différentes tables simultanément. See section 6.4.6 Syntaxe de DELETE.
PostgreSQL offre actuellement les avantages suivants sur MySQL :
Notez que comme nous connaissons le plan de développement de MySQL, nous avons inclus la table suivante, avec les version du serveur MySQL où les fonctionnalités seront supportées. Malheureusement, nous ne pouvions pas faire les mêmes comparaisons avec les fonctionnalités à venir de PostgreSQL, car nous ne connaissons pas le plan de développement de PostgreSQL.
| Fonctionnalité | version de MySQL |
| Sous-sélections | 4.1 |
| Clé étrangères | 5.0 (3.23 avec InnoDB)
|
| Vues | 5.0 |
| Procédures stockées | 5.0 |
| Triggers | 5.0 |
| Unions | 4.0 |
| Jointures totales | 4.1 |
| Contraintes | 4.1 ou 5.0 |
| Curseurs | 4.1 ou 5.0 |
| R-trees | 4.1 (pour les tables MyISAM) |
| Tables héritées | Non prévu |
| Type de données extensible | Non prévu |
Autres raisons de considérer PostgreSQL :
Les inconvénients de PostgreSQL face à MySQL :
VACUUM rend PostgreSQL difficile à utiliser en environnement
de production 24h/24 et 7j/7.
INSERT, DELETE et UPDATE sont plus lentes.
Pour une liste complète des inconvénients, examinez la première table de cette section.
Le seul test de vitesse Open Source que nous connaisssons et qui peut être
utilisé pour tester les performances de MySQL et de PostgreSQL (et d'autres
bases de données) est le nôtre. Il est disponible à l'adresse
http://www.mysql.com/information/benchmarks.html.
Nous avons demandé de nombreuses fois aux développeurs de PostgreSQL et aux utilisateurs de PostgreSQL de nous aider à développer et améliorer ce test, pour en faire le meilleur test possible, mais nous n'avons pas reçu de réponse de leur part.
Nous, les développeurs MySQL, avons, à cause de cela, passé de nombreuses heures à obtenir les meilleures performances de PostgreSQL pour ces tests, mais comme nous ne connaissons pas intimement le serveur PostgreSQL, nous sommes certains d'être passé à coté de certains points. Sur la page de test, nous avons documenté exactement comment nous avons exécuté le test, pour qu'il soit facile à tout le monde de reproduire et de confirmer nos résultats.
Les tests sont généralement exécutés avec et sans l'option --fast.
Lorsque l'option --fast est utilisée, nous tentons d'utiliser tous
les trucs connus du serveur pour que l'exécution soit aussi rapide que possible.
L'idée est que le mode normal doit montrer comment le serveur devrait se comporter
avec une configuration normale, et le mode --fast montre comment le serveur
se comporte si le développeur utilise toutes les extensions du serveur pour
accélérer son application.
Lorsque nous exécutons PostgreSQL avec l'option --fast, nous exécutons
la commande VACUUM après chaque modification importante de la table,
et après l'effacement de table, pour conserver la base dans un état parfait
pour les prochaines sélections. Le temps nécessaire à l'exécution de la commande
VACUUM est mesuré séparément.
Lorsque PostgreSQL 7.1.1 fonctionne, nous n'avons pu le faire fonctionner
avec l'option --fast car durant les test d'INSERT, le
postmaster (démon PostgreSQL) s'est arrété, et la base était tellement corrompue
qu'il a été impossible de redémarrer le postmaster. Après un deuxième
problème identique, nous avons décidé de reporter les tests
--fast jusqu'à la prochaine version de PostgreSQL. Les détais sur la
machine avec laquelle nous avons exécuté les tests sont disponible sur la page
de tests.
Avant de passer aux autres tests de performances que nous connaissons, nous souhaitons vous donner des détails sur le contexte des tests.
Il est très facile d'écrire un test qui montre que toutes les bases du monde sont les meilleures, en se limitant simplement aux points forts de la base, et en ne testant rien qui soit une faiblesse. De plus, si la conclusion se ramène à un seul chiffre, c'est encore plus facile.
Cela revient à mesurer la vitesse de MySQL par rapport à PostgreSQL en regardant simplement les temps moyens des tests de MySQL sur notre page. En se basant sur ces informations, notre serveur MySQL serait 40 fois plus rapide que PostgreSQL, ce qui est, bien sûr, faux. Nous pourrions même rendre les choses encore pires en prenant les tests où PostgreSQL a les pires performances, et dire que MySQL est plus de 2000 fois plus rapide que PostgreSQL.
Le fait est que MySQL fait un certain nombre d'optimisation que PostgreSQL ne fait pas. C'est aussi vrai, bien sûr, dans le sens inverse. Un optimiseur SQL est un programme complexe, et une compagnie peut passer des années à le rendre de plus en plus rapide.
Lorsque vous regardez les résultats des tests, vous devriez vous limiter aux opérations que vous utilisez dans votre application, et utiliser simplement ces résultats pour décider quelle base de données est la plus adaptée à vos besoins. Les résultats de tests vous montrent quelles opérations sont le point faible de chaque base, et vous donnent des indications sur ce qu'il faudra éviter de faire.
Nous connaissons deux tests de performances qui indiquent que PostgreSQL est plus rapide que MySQL. Ces deux tests sont faits dans un environnement multi-utilisateur, un test que nous, chez MySQL AB, nous n'avons pas eu le temps de mettre en place car c'est une tâche énorme de le faire pour que ce soit équitable pour chaque base.
Le premier est le test payant, effectué pour Great Bridge, une entreprise qui a tenté durant 16 mois de bâtir un modèle d'affaires avec PostgreSQL mais qui a désormais cessé les opérations. C'est probablement le pire test que nous ayons jamais vu. Non seulement ce test était bâti pour ne tester que les points forts de PostgreSQL, mais il était totalement déloyal pour toutes les autres bases de données utilisées dans le test.
Note : nous savons aussi que même certains des développeurs principaux de PostgreSQL n'ont pas aimé la manière avec laquelle Great Bridge a dirigé le test, et nous ne blâmons pas l'équipe de PostgreSQL pour ces tests.
Ce test a été condamné dans de nombreux articles et groupes d'utilisateurs, et nous ne citerons que quelques-uns des points qui étaient incorrects.
Open Source comme nous de
vérifier les résultats ou même de voir comment les tests ont
été mis en place. L'outil n'était même pas un véritable
outil de test de performances, mais une application de mise en place
et de tests. Dire que c'est un outil ``standard'' de tests est bien loin
de la vérité.
VACUUM avant le test) et optimisé le démarrage pour les
tests, ce qu'ils n'ont pas fait pour les autres bases. Ils disent
``Ce processus optimise les index et libère un peu d'espace sur le disque.
Les index optimisés améliorent les performances marginalement''. Nos tests
indiquent clairement la différence lorsqu'on exécute une série de
sélections sur une base qui a été entretenue avec VACUUM ou pas :
le facteur peut atteindre 10.
SELECTs et les JOINs (spécialement
après l'exécution de la commande VACUUM), mais n'est pas très performant
pour les INSERTs ou les UPDATE. Les tests semblent indiquer
que seuls des SELECT ont été exécutés. Cela peut facilement expliquer
le nombre de bons résultats pour PostgreSQL dans ce test. Les mauvais résultats
de MySQL seront évident un peu plus bas, dans ce document.
Tim Perdue, un inconditionnel de PostgreSQL et un utilisateur réticent de MySQL, publia une comparaison sur PHPbuilder (http://www.phpbuilder.com/columns/tim20001112.php3).
Lorsque nous avons eu connaissance de la comparaison, nous avons téléphoné à Tim Perdue à ce propos, car il y avait de nombreux résultats étranges dans ses publications. Par exemple, il statuait que MySQL avait un problème avec 5 utilisateurs durant ses tests, alors que nous avons des utilisateurs avec des machines similaires, qui utilisent MySQL avec plus de 2000 utilisateurs simultanés, et 400 requêtes par secondes. (Dans ce cas, la limite est la bande passante du réseau, pas le serveur SQL).
Il semblait qu'il utilisait un noyau Linux qui avait des problèmes avec les threads, comme les noyaux avant le 2.4 qui avait des problèmes avec les threads sur les machines à plusieurs processeurs. Nous avons documenté dans le manuel comment corriger ce problème, et Tim devrait être bientôt au courant de ce problème.
Les autres problèmes possibles pourraient provenir d'une vieille librairie glibc ou du fait que MySQL n'utilise pas une version exécutable de notre site web, qui est bâtie avec une version corrigée de glibc library. Dans ces cas, les symptômes sont ceux que Tim a mesuré.
Nous avons demandé à Tim d'avoir accès a ses données pour que nous puissions reproduire le test, et s'il pouvait vérifier la version de MySQL sur sa machine pour voir ce qui n'allait pas. Il a promis qu'il nous contacterait mais n'a rien fait à ce jour.
A cause de cela, nous ne pouvons pas non plus avoir confiance en ce test.
Avec le temps qui passe, les technologies évoluent, et les tests précédents ne sont désormais plus valables. Le serveur MySQL dispose d'un jeu de gestionnaires de tables, avec des choix très différents sur la vitesse et les fonctionnalités. See section 7 Types de tables MySQL. Il serait intéressant de voir comment les tests ci-dessus s'effectuent avec les différents gestionnaires de tables de MySQL. PostgreSQL a aussi, bien sûr, de nouvelles fonctionnalités depuis que ces tests ont été menés. Comme ces tests ne sont pas publiquement disponibles, il n'y a pas moyen pour nous de savoir comment les bases se comportent de nos jours avec ces tests.
Conclusion :
Les seuls tests qui existent aujourd'hui, disponibles au téléchargement
pour tous, et que vous pouvez exécuter avec MySQL, PostgreSQL sont les
tests de MySQL. Chez MySQL AB, nous croyons que les bases de données
Open Source devraient être testées avec des outils Open Source !
C'est le seul moyen de nous assurer que personne ne peut faire de tests
que personne ne peut reproduire, et les utiliser pour proclamer que sa
base est meilleure que les autres. Sans connaître le fond des choses,
il est impossible de répondre à une telle déclaration.
Ce que nous trouvons étrange est que chaque test que nous avons vu à propos de PostgreSQL est impossible à reproduire, et indique que PostgreSQL est le meilleur dans la plupart des tests, alors que les nôtres , que tout le monde peut reproduire, montrent le contraire. Avec cela, nous ne voulons pas dire que PostgreSQL n'est pas bon dans de nombreuses tâches (il l'est !!), ou qu'il n'est pas plus rapide que MySQL dans certaines conditions. Nous voulons juste voir un test équitable où PostgreSQL se comporte bien, pour que nous puissions avoir une compétition amicale !
Pour plus d'informations sur nos tests, voyez section 5.1.4 La suite de tests MySQL.
Nous travaillons actuellement sur une suite de tests de perfomance qui inclue des tests multi utilisateurs, et une meilleure documentation sur les tests individuels pour indiquer ce qu'ils font et comment ajouter d'autres tests à la suite.
Go to the first, previous, next, last section, table of contents.