1 Utilisez toujours le bon type de donn\u00e9es<\/strong><\/h2>\nL’une des meilleures pratiques MySQL les plus importantes consiste \u00e0 utiliser des types de donn\u00e9es bas\u00e9s sur la nature des donn\u00e9es. L’utilisation de types de donn\u00e9es non pertinents peut consommer plus d’espace ou entra\u00eener des erreurs.<\/p>\n
Par exemple\u00a0: l’utilisation de varchar (20) au lieu du type de donn\u00e9es DATETIME pour stocker les valeurs de date et d’heure entra\u00eenera des erreurs dans les calculs li\u00e9s \u00e0 la date et \u00e0 l’heure. De plus, il est possible que des donn\u00e9es non valides soient stock\u00e9es.<\/p>\n
2 Utilisez CHAR (1) sur VARCHAR (1)<\/strong><\/h2>\nVARCHAR (1) prend des octets suppl\u00e9mentaires pour stocker des informations, donc si vous encha\u00eenez un seul caract\u00e8re, il est pr\u00e9f\u00e9rable d’utiliser CHAR (1).<\/p>\n
3 Utilisez le type de donn\u00e9es CHAR pour stocker uniquement des donn\u00e9es de longueur fixe<\/strong><\/h2>\nPar exemple\u00a0: si la longueur des donn\u00e9es est inf\u00e9rieure \u00e0 1\u00a0000, l’utilisation de char (1\u00a0000) au lieu de varchar (1\u00a0000) consommera plus d’espace.<\/p>\n
4 \u00c9vitez d’utiliser des formats de date r\u00e9gionaux<\/strong><\/h2>\nLorsque vous utilisez le type de donn\u00e9es DATETIME ou DATE, utilisez toujours le format de date AAAA-MM-JJ ou le format de date ISO adapt\u00e9 \u00e0 votre moteur SQL. Les formats r\u00e9gionaux tels que JJ-MM-AAAA ou MM-JJ-AAAA ne seront pas stock\u00e9s correctement.<\/p>\n
5 colonnes de cl\u00e9 d’index<\/strong><\/h2>\nIl est souhaitable que la requ\u00eate renvoie le r\u00e9sultat rapidement, alors assurez-vous d’indexer les colonnes qui sont utilis\u00e9es dans les clauses JOIN.<\/p>\n
Si vous utilisez l’instruction UPDATE impliquant plusieurs tables, assurez-vous d’indexer toutes les colonnes utilis\u00e9es pour joindre les tables.<\/p>\n
6 N’utilisez pas de fonctions sur des colonnes index\u00e9es\u2026<\/strong><\/h2>\n\u2026 car alors l’indice perd sa raison d’\u00eatre.<\/p>\n
Par exemple, supposons que vous vouliez obtenir des donn\u00e9es o\u00f9 les deux premiers caract\u00e8res du code client sont AK. \u00c9crire:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\net n’\u00e9cris pas<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nPourquoi? Le premier exemple utilisera l’index, ce qui se traduira par un temps de r\u00e9ponse plus rapide.<\/p>\n
7 Utilisez SQL SELECT * uniquement si n\u00e9cessaire<\/strong><\/h2>\nSuite \u00e0 la liste des meilleures pratiques MySQL, n’utilisez pas aveugl\u00e9ment SELECT * dans le code. Si la table comporte plusieurs colonnes, elles seront toutes renvoy\u00e9es. Cela ralentira le temps de r\u00e9ponse, surtout si vous envoyez le r\u00e9sultat \u00e0 une application frontale.<\/p>\n
Au lieu de cela, tapez explicitement les noms de colonne qui sont r\u00e9ellement n\u00e9cessaires.<\/p>\n
Remarque: n’oubliez pas que toutes les instructions SELECT n\u00e9cessitent une clause WHERE.<\/p>\n
8 Utilisez la clause ORDER BY uniquement si n\u00e9cessaire<\/strong><\/h2>\nSi vous souhaitez afficher le r\u00e9sultat dans l’application frontale, laissez-le ORDER le jeu de r\u00e9sultats. Si vous faites cela dans SQL, le temps de r\u00e9ponse peut \u00eatre ralenti dans l’environnement multi-utilisateur.<\/p>\n
9 Choisissez un moteur de base de donn\u00e9es appropri\u00e9<\/strong><\/h2>\nSi vous d\u00e9veloppez une application qui lit les donn\u00e9es plus souvent qu’elle n’en \u00e9crit (par exemple un moteur de recherche), choisissez le moteur de stockage MyISAM.<\/p>\n
Choisir le mauvais moteur de stockage affectera les performances.<\/p>\n
10 Utilisez la clause EXISTS chaque fois que n\u00e9cessaire<\/strong><\/h2>\nPour v\u00e9rifier l’existence des donn\u00e9es, utilisez la clause EXISTS qui est plus rapide en temps de r\u00e9ponse. Par exemple, utilisez\u00a0:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNe pas utiliser :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLIQUEZ vos requ\u00eates SELECT<\/strong><\/h2>\nSi vous utilisez le mot-cl\u00e9 EXPLAIN, vous pouvez avoir un aper\u00e7u de ce que MySQL fait pour ex\u00e9cuter votre requ\u00eate. Cela peut vous aider \u00e0 d\u00e9tecter les probl\u00e8mes avec votre requ\u00eate ou les structures de table (par exemple, les goulots d’\u00e9tranglement).<\/p>\n
Une requ\u00eate EXPLAIN vous montre quels index sont utilis\u00e9s, comment la table est analys\u00e9e, tri\u00e9e, etc.<\/p>\n
Il suffit d’ajouter le mot-cl\u00e9 EXPLAIN devant une requ\u00eate SELECT (de pr\u00e9f\u00e9rence complexe avec des jointures). De plus, si vous utilisez phpmyadmin pour cela, vos r\u00e9sultats seront affich\u00e9s dans un joli tableau.<\/p>\n
12 Utilisez LIMIT 1 pour obtenir une ligne unique<\/strong><\/h2>\nParfois, vous savez \u00e0 l’avance que vous recherchez une seule ligne lorsque vous interrogez vos tables. Par exemple, vous pouvez r\u00e9cup\u00e9rer un enregistrement unique ou simplement v\u00e9rifier l’existence d’un nombre quelconque d’enregistrements qui satisfont votre clause WHERE.<\/p>\n
Dans de tels cas, vous voudrez utiliser la fonction de limite de MySQL pour augmenter les performances. Voici une autre des meilleures pratiques MySQL\u00a0: ajoutez simplement LIMIT\u00a01 \u00e0 votre requ\u00eate. De cette fa\u00e7on, le moteur de base de donn\u00e9es n’aura pas \u00e0 parcourir toute la table ou l’index. Il arr\u00eatera l’analyse lorsqu’il ne trouvera qu’un seul enregistrement de ce que vous recherchez.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ ce qu’il ne faut PAS faire\u00a0:
\n$r = mysql_query("SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ beaucoup mieux :
\n$r = mysql_query("SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nsi (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexer et utiliser les m\u00eames types de colonnes pour les jointures<\/strong><\/h2>\nUn autre conseil essentiel des meilleures pratiques MySQL – si votre application a de nombreuses requ\u00eates JOIN, assurez-vous que les colonnes que vous rejoignez sont index\u00e9es sur les deux tables. Cela affecte l’optimisation interne de l’op\u00e9ration de jointure par MySQL.<\/p>\n
De plus, les colonnes jointes doivent \u00eatre du m\u00eame type. Par exemple, si vous joignez une colonne DECIMAL \u00e0 une colonne INT d’une autre table, MySQL ne pourra utiliser aucun des index. M\u00eame les encodages de caract\u00e8res doivent \u00eatre du m\u00eame type pour les colonnes de type cha\u00eene.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ les deux colonnes d’\u00e9tat doivent \u00eatre index\u00e9es
\n\/\/ et elles doivent toutes deux avoir le m\u00eame type et le m\u00eame encodage de caract\u00e8res
\n\/\/ ou MySQL peut effectuer des analyses compl\u00e8tes de la table<\/p>\n
14 Masquer MySQL sur Internet<\/strong><\/h2>\nLes administrateurs de base de donn\u00e9es exp\u00e9riment\u00e9s et le personnel de s\u00e9curit\u00e9 le savent: n’h\u00e9bergez jamais la base de donn\u00e9es sous la racine du serveur Web.<\/p>\n
Pour les applications Web, MySQL doit \u00eatre cach\u00e9 derri\u00e8re un pare-feu. La communication doit \u00eatre activ\u00e9e uniquement entre les serveurs d’applications et vos serveurs Web.<\/p>\n
Une autre option consiste \u00e0 utiliser MySQL skip-networking. Lorsqu’il est activ\u00e9, MySQL n’\u00e9coute que les connexions socket locales et ignore tous les ports TCP.<\/p>\n
15 Utilisez les plus petits types de donn\u00e9es possibles<\/strong><\/h2>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b73d55e.jpg\")
<\/a><\/p>\nLaissez-moi vous raconter une histoire. Quand j’\u00e9tais \u00e0 l’universit\u00e9, la philosophie \u00e9tait que \u00abla m\u00e9moire est rare \u00bb. C’\u00e9tait l’\u00e9poque des disques durs de 256 Mo. De nos jours, personne ne semble se soucier d’un iota de la m\u00e9moire ou de l’espace disque. La nouvelle philosophie est que \u00abla m\u00e9moire est bon march\u00e9 \u00bb. C’est peut-\u00eatre vrai en dollars, mais la lecture de grands types de donn\u00e9es prend toujours plus de temps que la lecture de plus petits. Les types de donn\u00e9es volumineux n\u00e9cessitent davantage de secteurs de disque pour \u00eatre lus en m\u00e9moire.<\/p>\n
La morale est d’ignorer la tentation de sauter imm\u00e9diatement au plus grand type de donn\u00e9es lorsque vous concevez vos tables. Pensez \u00e0 utiliser un int au lieu d’un bigint.<\/p>\n
\u00c9vitez \u00e9galement les champs de texte largechar (255) lorsqu’un varchar ou un caract\u00e8re plus petit suffit.<\/p>\n
Si vous utilisez le bon type de donn\u00e9es, plus d’enregistrements tiendront dans la m\u00e9moire ou le bloc de cl\u00e9s d’index. Cela conduit \u00e0 moins de lectures et \u00e0 des performances plus rapides.<\/p>\n
16 Tirez parti de la mise en cache des requ\u00eates<\/strong><\/h2>\nLa mise en cache des requ\u00eates est l’une des m\u00e9thodes les plus efficaces pour am\u00e9liorer les performances. La plupart des serveurs MySQL l’ont activ\u00e9 par d\u00e9faut.<\/p>\n
Le cache de requ\u00eate stocke le texte d’une instruction SELECT avec le jeu de r\u00e9sultats correspondant. Si le serveur re\u00e7oit ult\u00e9rieurement une instruction identique, il r\u00e9cup\u00e9rera les r\u00e9sultats du cache de requ\u00eates plut\u00f4t que d’analyser et d’ex\u00e9cuter \u00e0 nouveau l’instruction. Le cache de requ\u00eates est partag\u00e9 entre les sessions, de sorte qu’un ensemble de r\u00e9sultats g\u00e9n\u00e9r\u00e9 par un client peut \u00eatre envoy\u00e9 en r\u00e9ponse \u00e0 la m\u00eame requ\u00eate \u00e9mise par un autre client.<\/p>\n
Cependant, aussi g\u00e9nial soit-il, la mise en cache des requ\u00eates a ses limites. Prenez la d\u00e9claration suivante :<\/p>\n
Le probl\u00e8me ici est que les requ\u00eates contiennent certaines fonctions non d\u00e9terministes, comme NOW() et RAND(). MySQL ne peut pas calculer de telles fonctions \u00e0 l’avance, elles finissent donc par ne pas \u00eatre mises en cache.<\/p>\n
Heureusement, il existe une solution simple \u00e0 cela: vous pouvez stocker les r\u00e9sultats de la fonction dans une variable.<\/p>\n
17 Ne modifiez pas les fichiers de vidage<\/strong><\/h2>\nLes fichiers de vidage sont tr\u00e8s trompeurs et peuvent entra\u00eener une corruption. Pourquoi? Si vous avez d\u00e9j\u00e0 vu les fichiers de vidage cr\u00e9\u00e9s par mysqldump, vous conviendrez qu’ils ressemblent \u00e0 des fichiers texte normaux et inoffensifs. C’est pourquoi la plupart des gens les \u00e9ditent dans un \u00e9diteur de texte standard, ce qui provoque l’apparition de corruptions.<\/p>\n
Si vous avez d\u00e9j\u00e0 essay\u00e9 de modifier des fichiers de vidage, vous avez rapidement appris qu’ils sont tout sauf un fichier texte. Ainsi, le seul moyen garanti d’\u00e9viter les probl\u00e8mes est de laisser les fichiers de vidage seuls.<\/p>\n
18 Utilisez le param\u00e8tre de taille de bloc MyISAM<\/strong><\/h2>\n
VARCHAR (1) prend des octets suppl\u00e9mentaires pour stocker des informations, donc si vous encha\u00eenez un seul caract\u00e8re, il est pr\u00e9f\u00e9rable d’utiliser CHAR (1).<\/p>\n
3 Utilisez le type de donn\u00e9es CHAR pour stocker uniquement des donn\u00e9es de longueur fixe<\/strong><\/h2>\nPar exemple\u00a0: si la longueur des donn\u00e9es est inf\u00e9rieure \u00e0 1\u00a0000, l’utilisation de char (1\u00a0000) au lieu de varchar (1\u00a0000) consommera plus d’espace.<\/p>\n
4 \u00c9vitez d’utiliser des formats de date r\u00e9gionaux<\/strong><\/h2>\nLorsque vous utilisez le type de donn\u00e9es DATETIME ou DATE, utilisez toujours le format de date AAAA-MM-JJ ou le format de date ISO adapt\u00e9 \u00e0 votre moteur SQL. Les formats r\u00e9gionaux tels que JJ-MM-AAAA ou MM-JJ-AAAA ne seront pas stock\u00e9s correctement.<\/p>\n
5 colonnes de cl\u00e9 d’index<\/strong><\/h2>\nIl est souhaitable que la requ\u00eate renvoie le r\u00e9sultat rapidement, alors assurez-vous d’indexer les colonnes qui sont utilis\u00e9es dans les clauses JOIN.<\/p>\n
Si vous utilisez l’instruction UPDATE impliquant plusieurs tables, assurez-vous d’indexer toutes les colonnes utilis\u00e9es pour joindre les tables.<\/p>\n
6 N’utilisez pas de fonctions sur des colonnes index\u00e9es\u2026<\/strong><\/h2>\n\u2026 car alors l’indice perd sa raison d’\u00eatre.<\/p>\n
Par exemple, supposons que vous vouliez obtenir des donn\u00e9es o\u00f9 les deux premiers caract\u00e8res du code client sont AK. \u00c9crire:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\net n’\u00e9cris pas<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nPourquoi? Le premier exemple utilisera l’index, ce qui se traduira par un temps de r\u00e9ponse plus rapide.<\/p>\n
7 Utilisez SQL SELECT * uniquement si n\u00e9cessaire<\/strong><\/h2>\nSuite \u00e0 la liste des meilleures pratiques MySQL, n’utilisez pas aveugl\u00e9ment SELECT * dans le code. Si la table comporte plusieurs colonnes, elles seront toutes renvoy\u00e9es. Cela ralentira le temps de r\u00e9ponse, surtout si vous envoyez le r\u00e9sultat \u00e0 une application frontale.<\/p>\n
Au lieu de cela, tapez explicitement les noms de colonne qui sont r\u00e9ellement n\u00e9cessaires.<\/p>\n
Remarque: n’oubliez pas que toutes les instructions SELECT n\u00e9cessitent une clause WHERE.<\/p>\n
8 Utilisez la clause ORDER BY uniquement si n\u00e9cessaire<\/strong><\/h2>\nSi vous souhaitez afficher le r\u00e9sultat dans l’application frontale, laissez-le ORDER le jeu de r\u00e9sultats. Si vous faites cela dans SQL, le temps de r\u00e9ponse peut \u00eatre ralenti dans l’environnement multi-utilisateur.<\/p>\n
9 Choisissez un moteur de base de donn\u00e9es appropri\u00e9<\/strong><\/h2>\nSi vous d\u00e9veloppez une application qui lit les donn\u00e9es plus souvent qu’elle n’en \u00e9crit (par exemple un moteur de recherche), choisissez le moteur de stockage MyISAM.<\/p>\n
Choisir le mauvais moteur de stockage affectera les performances.<\/p>\n
10 Utilisez la clause EXISTS chaque fois que n\u00e9cessaire<\/strong><\/h2>\nPour v\u00e9rifier l’existence des donn\u00e9es, utilisez la clause EXISTS qui est plus rapide en temps de r\u00e9ponse. Par exemple, utilisez\u00a0:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNe pas utiliser :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLIQUEZ vos requ\u00eates SELECT<\/strong><\/h2>\nSi vous utilisez le mot-cl\u00e9 EXPLAIN, vous pouvez avoir un aper\u00e7u de ce que MySQL fait pour ex\u00e9cuter votre requ\u00eate. Cela peut vous aider \u00e0 d\u00e9tecter les probl\u00e8mes avec votre requ\u00eate ou les structures de table (par exemple, les goulots d’\u00e9tranglement).<\/p>\n
Une requ\u00eate EXPLAIN vous montre quels index sont utilis\u00e9s, comment la table est analys\u00e9e, tri\u00e9e, etc.<\/p>\n
Il suffit d’ajouter le mot-cl\u00e9 EXPLAIN devant une requ\u00eate SELECT (de pr\u00e9f\u00e9rence complexe avec des jointures). De plus, si vous utilisez phpmyadmin pour cela, vos r\u00e9sultats seront affich\u00e9s dans un joli tableau.<\/p>\n
12 Utilisez LIMIT 1 pour obtenir une ligne unique<\/strong><\/h2>\nParfois, vous savez \u00e0 l’avance que vous recherchez une seule ligne lorsque vous interrogez vos tables. Par exemple, vous pouvez r\u00e9cup\u00e9rer un enregistrement unique ou simplement v\u00e9rifier l’existence d’un nombre quelconque d’enregistrements qui satisfont votre clause WHERE.<\/p>\n
Dans de tels cas, vous voudrez utiliser la fonction de limite de MySQL pour augmenter les performances. Voici une autre des meilleures pratiques MySQL\u00a0: ajoutez simplement LIMIT\u00a01 \u00e0 votre requ\u00eate. De cette fa\u00e7on, le moteur de base de donn\u00e9es n’aura pas \u00e0 parcourir toute la table ou l’index. Il arr\u00eatera l’analyse lorsqu’il ne trouvera qu’un seul enregistrement de ce que vous recherchez.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ ce qu’il ne faut PAS faire\u00a0:
\n$r = mysql_query("SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ beaucoup mieux :
\n$r = mysql_query("SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nsi (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexer et utiliser les m\u00eames types de colonnes pour les jointures<\/strong><\/h2>\nUn autre conseil essentiel des meilleures pratiques MySQL – si votre application a de nombreuses requ\u00eates JOIN, assurez-vous que les colonnes que vous rejoignez sont index\u00e9es sur les deux tables. Cela affecte l’optimisation interne de l’op\u00e9ration de jointure par MySQL.<\/p>\n
De plus, les colonnes jointes doivent \u00eatre du m\u00eame type. Par exemple, si vous joignez une colonne DECIMAL \u00e0 une colonne INT d’une autre table, MySQL ne pourra utiliser aucun des index. M\u00eame les encodages de caract\u00e8res doivent \u00eatre du m\u00eame type pour les colonnes de type cha\u00eene.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ les deux colonnes d’\u00e9tat doivent \u00eatre index\u00e9es
\n\/\/ et elles doivent toutes deux avoir le m\u00eame type et le m\u00eame encodage de caract\u00e8res
\n\/\/ ou MySQL peut effectuer des analyses compl\u00e8tes de la table<\/p>\n
14 Masquer MySQL sur Internet<\/strong><\/h2>\nLes administrateurs de base de donn\u00e9es exp\u00e9riment\u00e9s et le personnel de s\u00e9curit\u00e9 le savent: n’h\u00e9bergez jamais la base de donn\u00e9es sous la racine du serveur Web.<\/p>\n
Pour les applications Web, MySQL doit \u00eatre cach\u00e9 derri\u00e8re un pare-feu. La communication doit \u00eatre activ\u00e9e uniquement entre les serveurs d’applications et vos serveurs Web.<\/p>\n
Une autre option consiste \u00e0 utiliser MySQL skip-networking. Lorsqu’il est activ\u00e9, MySQL n’\u00e9coute que les connexions socket locales et ignore tous les ports TCP.<\/p>\n
15 Utilisez les plus petits types de donn\u00e9es possibles<\/strong><\/h2>\n<\/a><\/p>\nLaissez-moi vous raconter une histoire. Quand j’\u00e9tais \u00e0 l’universit\u00e9, la philosophie \u00e9tait que \u00abla m\u00e9moire est rare \u00bb. C’\u00e9tait l’\u00e9poque des disques durs de 256 Mo. De nos jours, personne ne semble se soucier d’un iota de la m\u00e9moire ou de l’espace disque. La nouvelle philosophie est que \u00abla m\u00e9moire est bon march\u00e9 \u00bb. C’est peut-\u00eatre vrai en dollars, mais la lecture de grands types de donn\u00e9es prend toujours plus de temps que la lecture de plus petits. Les types de donn\u00e9es volumineux n\u00e9cessitent davantage de secteurs de disque pour \u00eatre lus en m\u00e9moire.<\/p>\n
La morale est d’ignorer la tentation de sauter imm\u00e9diatement au plus grand type de donn\u00e9es lorsque vous concevez vos tables. Pensez \u00e0 utiliser un int au lieu d’un bigint.<\/p>\n
\u00c9vitez \u00e9galement les champs de texte largechar (255) lorsqu’un varchar ou un caract\u00e8re plus petit suffit.<\/p>\n
Si vous utilisez le bon type de donn\u00e9es, plus d’enregistrements tiendront dans la m\u00e9moire ou le bloc de cl\u00e9s d’index. Cela conduit \u00e0 moins de lectures et \u00e0 des performances plus rapides.<\/p>\n
16 Tirez parti de la mise en cache des requ\u00eates<\/strong><\/h2>\nLa mise en cache des requ\u00eates est l’une des m\u00e9thodes les plus efficaces pour am\u00e9liorer les performances. La plupart des serveurs MySQL l’ont activ\u00e9 par d\u00e9faut.<\/p>\n
Le cache de requ\u00eate stocke le texte d’une instruction SELECT avec le jeu de r\u00e9sultats correspondant. Si le serveur re\u00e7oit ult\u00e9rieurement une instruction identique, il r\u00e9cup\u00e9rera les r\u00e9sultats du cache de requ\u00eates plut\u00f4t que d’analyser et d’ex\u00e9cuter \u00e0 nouveau l’instruction. Le cache de requ\u00eates est partag\u00e9 entre les sessions, de sorte qu’un ensemble de r\u00e9sultats g\u00e9n\u00e9r\u00e9 par un client peut \u00eatre envoy\u00e9 en r\u00e9ponse \u00e0 la m\u00eame requ\u00eate \u00e9mise par un autre client.<\/p>\n
Cependant, aussi g\u00e9nial soit-il, la mise en cache des requ\u00eates a ses limites. Prenez la d\u00e9claration suivante :<\/p>\n
Le probl\u00e8me ici est que les requ\u00eates contiennent certaines fonctions non d\u00e9terministes, comme NOW() et RAND(). MySQL ne peut pas calculer de telles fonctions \u00e0 l’avance, elles finissent donc par ne pas \u00eatre mises en cache.<\/p>\n
Heureusement, il existe une solution simple \u00e0 cela: vous pouvez stocker les r\u00e9sultats de la fonction dans une variable.<\/p>\n
17 Ne modifiez pas les fichiers de vidage<\/strong><\/h2>\nLes fichiers de vidage sont tr\u00e8s trompeurs et peuvent entra\u00eener une corruption. Pourquoi? Si vous avez d\u00e9j\u00e0 vu les fichiers de vidage cr\u00e9\u00e9s par mysqldump, vous conviendrez qu’ils ressemblent \u00e0 des fichiers texte normaux et inoffensifs. C’est pourquoi la plupart des gens les \u00e9ditent dans un \u00e9diteur de texte standard, ce qui provoque l’apparition de corruptions.<\/p>\n
Si vous avez d\u00e9j\u00e0 essay\u00e9 de modifier des fichiers de vidage, vous avez rapidement appris qu’ils sont tout sauf un fichier texte. Ainsi, le seul moyen garanti d’\u00e9viter les probl\u00e8mes est de laisser les fichiers de vidage seuls.<\/p>\n
18 Utilisez le param\u00e8tre de taille de bloc MyISAM<\/strong><\/h2>\n
Lorsque vous utilisez le type de donn\u00e9es DATETIME ou DATE, utilisez toujours le format de date AAAA-MM-JJ ou le format de date ISO adapt\u00e9 \u00e0 votre moteur SQL. Les formats r\u00e9gionaux tels que JJ-MM-AAAA ou MM-JJ-AAAA ne seront pas stock\u00e9s correctement.<\/p>\n
5 colonnes de cl\u00e9 d’index<\/strong><\/h2>\nIl est souhaitable que la requ\u00eate renvoie le r\u00e9sultat rapidement, alors assurez-vous d’indexer les colonnes qui sont utilis\u00e9es dans les clauses JOIN.<\/p>\n
Si vous utilisez l’instruction UPDATE impliquant plusieurs tables, assurez-vous d’indexer toutes les colonnes utilis\u00e9es pour joindre les tables.<\/p>\n
6 N’utilisez pas de fonctions sur des colonnes index\u00e9es\u2026<\/strong><\/h2>\n\u2026 car alors l’indice perd sa raison d’\u00eatre.<\/p>\n
Par exemple, supposons que vous vouliez obtenir des donn\u00e9es o\u00f9 les deux premiers caract\u00e8res du code client sont AK. \u00c9crire:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\net n’\u00e9cris pas<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nPourquoi? Le premier exemple utilisera l’index, ce qui se traduira par un temps de r\u00e9ponse plus rapide.<\/p>\n
7 Utilisez SQL SELECT * uniquement si n\u00e9cessaire<\/strong><\/h2>\nSuite \u00e0 la liste des meilleures pratiques MySQL, n’utilisez pas aveugl\u00e9ment SELECT * dans le code. Si la table comporte plusieurs colonnes, elles seront toutes renvoy\u00e9es. Cela ralentira le temps de r\u00e9ponse, surtout si vous envoyez le r\u00e9sultat \u00e0 une application frontale.<\/p>\n
Au lieu de cela, tapez explicitement les noms de colonne qui sont r\u00e9ellement n\u00e9cessaires.<\/p>\n
Remarque: n’oubliez pas que toutes les instructions SELECT n\u00e9cessitent une clause WHERE.<\/p>\n
8 Utilisez la clause ORDER BY uniquement si n\u00e9cessaire<\/strong><\/h2>\nSi vous souhaitez afficher le r\u00e9sultat dans l’application frontale, laissez-le ORDER le jeu de r\u00e9sultats. Si vous faites cela dans SQL, le temps de r\u00e9ponse peut \u00eatre ralenti dans l’environnement multi-utilisateur.<\/p>\n
9 Choisissez un moteur de base de donn\u00e9es appropri\u00e9<\/strong><\/h2>\nSi vous d\u00e9veloppez une application qui lit les donn\u00e9es plus souvent qu’elle n’en \u00e9crit (par exemple un moteur de recherche), choisissez le moteur de stockage MyISAM.<\/p>\n
Choisir le mauvais moteur de stockage affectera les performances.<\/p>\n
10 Utilisez la clause EXISTS chaque fois que n\u00e9cessaire<\/strong><\/h2>\nPour v\u00e9rifier l’existence des donn\u00e9es, utilisez la clause EXISTS qui est plus rapide en temps de r\u00e9ponse. Par exemple, utilisez\u00a0:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nNe pas utiliser :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLIQUEZ vos requ\u00eates SELECT<\/strong><\/h2>\nSi vous utilisez le mot-cl\u00e9 EXPLAIN, vous pouvez avoir un aper\u00e7u de ce que MySQL fait pour ex\u00e9cuter votre requ\u00eate. Cela peut vous aider \u00e0 d\u00e9tecter les probl\u00e8mes avec votre requ\u00eate ou les structures de table (par exemple, les goulots d’\u00e9tranglement).<\/p>\n
Une requ\u00eate EXPLAIN vous montre quels index sont utilis\u00e9s, comment la table est analys\u00e9e, tri\u00e9e, etc.<\/p>\n
Il suffit d’ajouter le mot-cl\u00e9 EXPLAIN devant une requ\u00eate SELECT (de pr\u00e9f\u00e9rence complexe avec des jointures). De plus, si vous utilisez phpmyadmin pour cela, vos r\u00e9sultats seront affich\u00e9s dans un joli tableau.<\/p>\n
12 Utilisez LIMIT 1 pour obtenir une ligne unique<\/strong><\/h2>\nParfois, vous savez \u00e0 l’avance que vous recherchez une seule ligne lorsque vous interrogez vos tables. Par exemple, vous pouvez r\u00e9cup\u00e9rer un enregistrement unique ou simplement v\u00e9rifier l’existence d’un nombre quelconque d’enregistrements qui satisfont votre clause WHERE.<\/p>\n
Dans de tels cas, vous voudrez utiliser la fonction de limite de MySQL pour augmenter les performances. Voici une autre des meilleures pratiques MySQL\u00a0: ajoutez simplement LIMIT\u00a01 \u00e0 votre requ\u00eate. De cette fa\u00e7on, le moteur de base de donn\u00e9es n’aura pas \u00e0 parcourir toute la table ou l’index. Il arr\u00eatera l’analyse lorsqu’il ne trouvera qu’un seul enregistrement de ce que vous recherchez.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ ce qu’il ne faut PAS faire\u00a0:
\n$r = mysql_query("SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ beaucoup mieux :
\n$r = mysql_query("SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nsi (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexer et utiliser les m\u00eames types de colonnes pour les jointures<\/strong><\/h2>\nUn autre conseil essentiel des meilleures pratiques MySQL – si votre application a de nombreuses requ\u00eates JOIN, assurez-vous que les colonnes que vous rejoignez sont index\u00e9es sur les deux tables. Cela affecte l’optimisation interne de l’op\u00e9ration de jointure par MySQL.<\/p>\n
De plus, les colonnes jointes doivent \u00eatre du m\u00eame type. Par exemple, si vous joignez une colonne DECIMAL \u00e0 une colonne INT d’une autre table, MySQL ne pourra utiliser aucun des index. M\u00eame les encodages de caract\u00e8res doivent \u00eatre du m\u00eame type pour les colonnes de type cha\u00eene.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ les deux colonnes d’\u00e9tat doivent \u00eatre index\u00e9es
\n\/\/ et elles doivent toutes deux avoir le m\u00eame type et le m\u00eame encodage de caract\u00e8res
\n\/\/ ou MySQL peut effectuer des analyses compl\u00e8tes de la table<\/p>\n
14 Masquer MySQL sur Internet<\/strong><\/h2>\nLes administrateurs de base de donn\u00e9es exp\u00e9riment\u00e9s et le personnel de s\u00e9curit\u00e9 le savent: n’h\u00e9bergez jamais la base de donn\u00e9es sous la racine du serveur Web.<\/p>\n
Pour les applications Web, MySQL doit \u00eatre cach\u00e9 derri\u00e8re un pare-feu. La communication doit \u00eatre activ\u00e9e uniquement entre les serveurs d’applications et vos serveurs Web.<\/p>\n
Une autre option consiste \u00e0 utiliser MySQL skip-networking. Lorsqu’il est activ\u00e9, MySQL n’\u00e9coute que les connexions socket locales et ignore tous les ports TCP.<\/p>\n
15 Utilisez les plus petits types de donn\u00e9es possibles<\/strong><\/h2>\n<\/a><\/p>\nLaissez-moi vous raconter une histoire. Quand j’\u00e9tais \u00e0 l’universit\u00e9, la philosophie \u00e9tait que \u00abla m\u00e9moire est rare \u00bb. C’\u00e9tait l’\u00e9poque des disques durs de 256 Mo. De nos jours, personne ne semble se soucier d’un iota de la m\u00e9moire ou de l’espace disque. La nouvelle philosophie est que \u00abla m\u00e9moire est bon march\u00e9 \u00bb. C’est peut-\u00eatre vrai en dollars, mais la lecture de grands types de donn\u00e9es prend toujours plus de temps que la lecture de plus petits. Les types de donn\u00e9es volumineux n\u00e9cessitent davantage de secteurs de disque pour \u00eatre lus en m\u00e9moire.<\/p>\n
La morale est d’ignorer la tentation de sauter imm\u00e9diatement au plus grand type de donn\u00e9es lorsque vous concevez vos tables. Pensez \u00e0 utiliser un int au lieu d’un bigint.<\/p>\n
\u00c9vitez \u00e9galement les champs de texte largechar (255) lorsqu’un varchar ou un caract\u00e8re plus petit suffit.<\/p>\n
Si vous utilisez le bon type de donn\u00e9es, plus d’enregistrements tiendront dans la m\u00e9moire ou le bloc de cl\u00e9s d’index. Cela conduit \u00e0 moins de lectures et \u00e0 des performances plus rapides.<\/p>\n
16 Tirez parti de la mise en cache des requ\u00eates<\/strong><\/h2>\nLa mise en cache des requ\u00eates est l’une des m\u00e9thodes les plus efficaces pour am\u00e9liorer les performances. La plupart des serveurs MySQL l’ont activ\u00e9 par d\u00e9faut.<\/p>\n
Le cache de requ\u00eate stocke le texte d’une instruction SELECT avec le jeu de r\u00e9sultats correspondant. Si le serveur re\u00e7oit ult\u00e9rieurement une instruction identique, il r\u00e9cup\u00e9rera les r\u00e9sultats du cache de requ\u00eates plut\u00f4t que d’analyser et d’ex\u00e9cuter \u00e0 nouveau l’instruction. Le cache de requ\u00eates est partag\u00e9 entre les sessions, de sorte qu’un ensemble de r\u00e9sultats g\u00e9n\u00e9r\u00e9 par un client peut \u00eatre envoy\u00e9 en r\u00e9ponse \u00e0 la m\u00eame requ\u00eate \u00e9mise par un autre client.<\/p>\n
Cependant, aussi g\u00e9nial soit-il, la mise en cache des requ\u00eates a ses limites. Prenez la d\u00e9claration suivante :<\/p>\n
Le probl\u00e8me ici est que les requ\u00eates contiennent certaines fonctions non d\u00e9terministes, comme NOW() et RAND(). MySQL ne peut pas calculer de telles fonctions \u00e0 l’avance, elles finissent donc par ne pas \u00eatre mises en cache.<\/p>\n
Heureusement, il existe une solution simple \u00e0 cela: vous pouvez stocker les r\u00e9sultats de la fonction dans une variable.<\/p>\n
17 Ne modifiez pas les fichiers de vidage<\/strong><\/h2>\nLes fichiers de vidage sont tr\u00e8s trompeurs et peuvent entra\u00eener une corruption. Pourquoi? Si vous avez d\u00e9j\u00e0 vu les fichiers de vidage cr\u00e9\u00e9s par mysqldump, vous conviendrez qu’ils ressemblent \u00e0 des fichiers texte normaux et inoffensifs. C’est pourquoi la plupart des gens les \u00e9ditent dans un \u00e9diteur de texte standard, ce qui provoque l’apparition de corruptions.<\/p>\n
Si vous avez d\u00e9j\u00e0 essay\u00e9 de modifier des fichiers de vidage, vous avez rapidement appris qu’ils sont tout sauf un fichier texte. Ainsi, le seul moyen garanti d’\u00e9viter les probl\u00e8mes est de laisser les fichiers de vidage seuls.<\/p>\n
18 Utilisez le param\u00e8tre de taille de bloc MyISAM<\/strong><\/h2>\n
\u2026 car alors l’indice perd sa raison d’\u00eatre.<\/p>\n
Par exemple, supposons que vous vouliez obtenir des donn\u00e9es o\u00f9 les deux premiers caract\u00e8res du code client sont AK. \u00c9crire:<\/p>\n
et n’\u00e9cris pas<\/p>\n Pourquoi? Le premier exemple utilisera l’index, ce qui se traduira par un temps de r\u00e9ponse plus rapide.<\/p>\n Suite \u00e0 la liste des meilleures pratiques MySQL, n’utilisez pas aveugl\u00e9ment SELECT * dans le code. Si la table comporte plusieurs colonnes, elles seront toutes renvoy\u00e9es. Cela ralentira le temps de r\u00e9ponse, surtout si vous envoyez le r\u00e9sultat \u00e0 une application frontale.<\/p>\n Au lieu de cela, tapez explicitement les noms de colonne qui sont r\u00e9ellement n\u00e9cessaires.<\/p>\n Remarque: n’oubliez pas que toutes les instructions SELECT n\u00e9cessitent une clause WHERE.<\/p>\n Si vous souhaitez afficher le r\u00e9sultat dans l’application frontale, laissez-le ORDER le jeu de r\u00e9sultats. Si vous faites cela dans SQL, le temps de r\u00e9ponse peut \u00eatre ralenti dans l’environnement multi-utilisateur.<\/p>\n Si vous d\u00e9veloppez une application qui lit les donn\u00e9es plus souvent qu’elle n’en \u00e9crit (par exemple un moteur de recherche), choisissez le moteur de stockage MyISAM.<\/p>\n Choisir le mauvais moteur de stockage affectera les performances.<\/p>\n Pour v\u00e9rifier l’existence des donn\u00e9es, utilisez la clause EXISTS qui est plus rapide en temps de r\u00e9ponse. Par exemple, utilisez\u00a0:<\/p>\n Ne pas utiliser :<\/p>\n Si vous utilisez le mot-cl\u00e9 EXPLAIN, vous pouvez avoir un aper\u00e7u de ce que MySQL fait pour ex\u00e9cuter votre requ\u00eate. Cela peut vous aider \u00e0 d\u00e9tecter les probl\u00e8mes avec votre requ\u00eate ou les structures de table (par exemple, les goulots d’\u00e9tranglement).<\/p>\n Une requ\u00eate EXPLAIN vous montre quels index sont utilis\u00e9s, comment la table est analys\u00e9e, tri\u00e9e, etc.<\/p>\n Il suffit d’ajouter le mot-cl\u00e9 EXPLAIN devant une requ\u00eate SELECT (de pr\u00e9f\u00e9rence complexe avec des jointures). De plus, si vous utilisez phpmyadmin pour cela, vos r\u00e9sultats seront affich\u00e9s dans un joli tableau.<\/p>\n Parfois, vous savez \u00e0 l’avance que vous recherchez une seule ligne lorsque vous interrogez vos tables. Par exemple, vous pouvez r\u00e9cup\u00e9rer un enregistrement unique ou simplement v\u00e9rifier l’existence d’un nombre quelconque d’enregistrements qui satisfont votre clause WHERE.<\/p>\n Dans de tels cas, vous voudrez utiliser la fonction de limite de MySQL pour augmenter les performances. Voici une autre des meilleures pratiques MySQL\u00a0: ajoutez simplement LIMIT\u00a01 \u00e0 votre requ\u00eate. De cette fa\u00e7on, le moteur de base de donn\u00e9es n’aura pas \u00e0 parcourir toute la table ou l’index. Il arr\u00eatera l’analyse lorsqu’il ne trouvera qu’un seul enregistrement de ce que vous recherchez.<\/p>\n \/\/ ce qu’il ne faut PAS faire\u00a0: \/\/ beaucoup mieux : Un autre conseil essentiel des meilleures pratiques MySQL – si votre application a de nombreuses requ\u00eates JOIN, assurez-vous que les colonnes que vous rejoignez sont index\u00e9es sur les deux tables. Cela affecte l’optimisation interne de l’op\u00e9ration de jointure par MySQL.<\/p>\n De plus, les colonnes jointes doivent \u00eatre du m\u00eame type. Par exemple, si vous joignez une colonne DECIMAL \u00e0 une colonne INT d’une autre table, MySQL ne pourra utiliser aucun des index. M\u00eame les encodages de caract\u00e8res doivent \u00eatre du m\u00eame type pour les colonnes de type cha\u00eene.<\/p>\n \/\/ les deux colonnes d’\u00e9tat doivent \u00eatre index\u00e9es Les administrateurs de base de donn\u00e9es exp\u00e9riment\u00e9s et le personnel de s\u00e9curit\u00e9 le savent: n’h\u00e9bergez jamais la base de donn\u00e9es sous la racine du serveur Web.<\/p>\n Pour les applications Web, MySQL doit \u00eatre cach\u00e9 derri\u00e8re un pare-feu. La communication doit \u00eatre activ\u00e9e uniquement entre les serveurs d’applications et vos serveurs Web.<\/p>\n Une autre option consiste \u00e0 utiliser MySQL skip-networking. Lorsqu’il est activ\u00e9, MySQL n’\u00e9coute que les connexions socket locales et ignore tous les ports TCP.<\/p>\n Laissez-moi vous raconter une histoire. Quand j’\u00e9tais \u00e0 l’universit\u00e9, la philosophie \u00e9tait que \u00abla m\u00e9moire est rare \u00bb. C’\u00e9tait l’\u00e9poque des disques durs de 256 Mo. De nos jours, personne ne semble se soucier d’un iota de la m\u00e9moire ou de l’espace disque. La nouvelle philosophie est que \u00abla m\u00e9moire est bon march\u00e9 \u00bb. C’est peut-\u00eatre vrai en dollars, mais la lecture de grands types de donn\u00e9es prend toujours plus de temps que la lecture de plus petits. Les types de donn\u00e9es volumineux n\u00e9cessitent davantage de secteurs de disque pour \u00eatre lus en m\u00e9moire.<\/p>\n La morale est d’ignorer la tentation de sauter imm\u00e9diatement au plus grand type de donn\u00e9es lorsque vous concevez vos tables. Pensez \u00e0 utiliser un int au lieu d’un bigint.<\/p>\n \u00c9vitez \u00e9galement les champs de texte largechar (255) lorsqu’un varchar ou un caract\u00e8re plus petit suffit.<\/p>\n Si vous utilisez le bon type de donn\u00e9es, plus d’enregistrements tiendront dans la m\u00e9moire ou le bloc de cl\u00e9s d’index. Cela conduit \u00e0 moins de lectures et \u00e0 des performances plus rapides.<\/p>\n La mise en cache des requ\u00eates est l’une des m\u00e9thodes les plus efficaces pour am\u00e9liorer les performances. La plupart des serveurs MySQL l’ont activ\u00e9 par d\u00e9faut.<\/p>\n Le cache de requ\u00eate stocke le texte d’une instruction SELECT avec le jeu de r\u00e9sultats correspondant. Si le serveur re\u00e7oit ult\u00e9rieurement une instruction identique, il r\u00e9cup\u00e9rera les r\u00e9sultats du cache de requ\u00eates plut\u00f4t que d’analyser et d’ex\u00e9cuter \u00e0 nouveau l’instruction. Le cache de requ\u00eates est partag\u00e9 entre les sessions, de sorte qu’un ensemble de r\u00e9sultats g\u00e9n\u00e9r\u00e9 par un client peut \u00eatre envoy\u00e9 en r\u00e9ponse \u00e0 la m\u00eame requ\u00eate \u00e9mise par un autre client.<\/p>\n Cependant, aussi g\u00e9nial soit-il, la mise en cache des requ\u00eates a ses limites. Prenez la d\u00e9claration suivante :<\/p>\n Le probl\u00e8me ici est que les requ\u00eates contiennent certaines fonctions non d\u00e9terministes, comme NOW() et RAND(). MySQL ne peut pas calculer de telles fonctions \u00e0 l’avance, elles finissent donc par ne pas \u00eatre mises en cache.<\/p>\n Heureusement, il existe une solution simple \u00e0 cela: vous pouvez stocker les r\u00e9sultats de la fonction dans une variable.<\/p>\n Les fichiers de vidage sont tr\u00e8s trompeurs et peuvent entra\u00eener une corruption. Pourquoi? Si vous avez d\u00e9j\u00e0 vu les fichiers de vidage cr\u00e9\u00e9s par mysqldump, vous conviendrez qu’ils ressemblent \u00e0 des fichiers texte normaux et inoffensifs. C’est pourquoi la plupart des gens les \u00e9ditent dans un \u00e9diteur de texte standard, ce qui provoque l’apparition de corruptions.<\/p>\n Si vous avez d\u00e9j\u00e0 essay\u00e9 de modifier des fichiers de vidage, vous avez rapidement appris qu’ils sont tout sauf un fichier texte. Ainsi, le seul moyen garanti d’\u00e9viter les probl\u00e8mes est de laisser les fichiers de vidage seuls.<\/p>\nSELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\nSELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\n7 Utilisez SQL SELECT * uniquement si n\u00e9cessaire<\/strong><\/h2>\n
8 Utilisez la clause ORDER BY uniquement si n\u00e9cessaire<\/strong><\/h2>\n
9 Choisissez un moteur de base de donn\u00e9es appropri\u00e9<\/strong><\/h2>\n
10 Utilisez la clause EXISTS chaque fois que n\u00e9cessaire<\/strong><\/h2>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nIf (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLIQUEZ vos requ\u00eates SELECT<\/strong><\/h2>\n
12 Utilisez LIMIT 1 pour obtenir une ligne unique<\/strong><\/h2>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n
\n$r = mysql_query("SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\n$r = mysql_query("SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nsi (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n13 Indexer et utiliser les m\u00eames types de colonnes pour les jointures<\/strong><\/h2>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n
\n\/\/ et elles doivent toutes deux avoir le m\u00eame type et le m\u00eame encodage de caract\u00e8res
\n\/\/ ou MySQL peut effectuer des analyses compl\u00e8tes de la table<\/p>\n14 Masquer MySQL sur Internet<\/strong><\/h2>\n
15 Utilisez les plus petits types de donn\u00e9es possibles<\/strong><\/h2>\n
<\/a><\/p>\n16 Tirez parti de la mise en cache des requ\u00eates<\/strong><\/h2>\n
17 Ne modifiez pas les fichiers de vidage<\/strong><\/h2>\n
18 Utilisez le param\u00e8tre de taille de bloc MyISAM<\/strong><\/h2>\n
![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b8518b8.jpg\")
<\/a><\/p>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b96bb8a.jpg\")
<\/a><\/p>\n