Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
A
ApplicationsBD_CHEVALIER_TONDON_KELBERT
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
KELBERT Paul
ApplicationsBD_CHEVALIER_TONDON_KELBERT
Commits
ba997b98
Commit
ba997b98
authored
5 years ago
by
Tondon César
Browse files
Options
Downloads
Patches
Plain Diff
preparation séance trois
parent
72d466c8
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
Seance3/preparation seance 3.txt
+64
-0
64 additions, 0 deletions
Seance3/preparation seance 3.txt
with
64 additions
and
0 deletions
Seance3/preparation seance 3.txt
0 → 100644
+
64
−
0
View file @
ba997b98
Partie 1 : mesurer les performances et utiliser des index
1. Code pour mesurer le temps d'exécution
<?php
$debut = microtime(true);
/**
* Suite d'instruction ...
*/
$fin = microtime(true);
$dureeExecution = $fin - $debut;
echo "L'exécution de ce code a duré $dureeExecution secondes\n";
?>
2. Intérêt d'index :
Les index sont utilisés pour rechercher rapidement des lignes avec des valeurs de
colonne spécifiques. Sans index, MySQL doit commencer par la première ligne, puis
parcourir toute la table pour trouver les lignes pertinentes. Plus la table est grande,
plus cela coûte. Si la table a un index pour les colonnes en question, MySQL peut
rapidement déterminer la position à rechercher au milieu du fichier de données sans avoir à
regarder toutes les données. Ceci est beaucoup plus rapide que la lecture séquentielle
de chaque ligne.
Principe de fonctionnement :
- Pour trouver rapidement les lignes correspondant à une clause WHERE.
- Pour éliminer les lignes de la considération. S'il y a un choix entre plusieurs index, MySQL
utilise normalement l'index qui trouve le plus petit nombre de lignes.
- Par exemple, si vous avez un index à trois colonnes sur (col1, col2, col3), vous avez
indexé les capacités de recherche sur (col1), (col1, col2) et (col1, col2, col3).
- Pour récupérer des lignes à partir d'autres tables lors de l'exécution de jointures.
MySQL peut utiliser les index des colonnes plus efficacement s'ils sont déclarés de même type
et de même taille. Dans ce contexte, VARCHAR et CHAR sont considérés comme identiques s'ils sont
déclarés comme ayant la même taille. Par exemple, VARCHAR (10) et CHAR (10) ont la même taille,
mais VARCHAR (10) et CHAR (15) ne le sont pas.
- Pour les comparaisons entre les colonnes de chaînes non binaires, les deux colonnes doivent
utiliser le même jeu de caractères.
- La comparaison de colonnes différentes peut empêcher l'utilisation d'index si les valeurs ne
peuvent pas être comparées directement sans conversion. Pour une valeur donnée telle que 1 dans la
colonne numérique, il peut être égal à n'importe quel nombre de valeurs dans la colonne chaîne comme
«1», «1», «00001» ou «01 .e1». Cela exclut l'utilisation de tout index pour la colonne de chaîne.
- Pour trouver la valeur MIN () ou MAX () pour une colonne indexée spécifique key_col. Ceci est
optimisé par un préprocesseur qui vérifie si vous utilisez WHERE key_part_N = constant sur toutes les
parties clés qui se produisent avant key_col dans l'index. Dans ce cas, MySQL effectue une recherche
de clé unique pour chaque expression MIN () ou MAX () et la remplace par une constante. Si toutes les
expressions sont remplacées par des constantes, la requête retourne immédiatement.
Partie 2 : observer l'orm, améliorer les performances avec des chargements liés
1. Structure du log de requêtes dans Eloquent
2. Le problème des N+1 query
Le problème est que chaque requête a un peu de surcharge. Il est beaucoup plus rapide d'émettre 1 requête
qui renvoie 100 résultats que d'émettre 100 requêtes qui renvoient chacune 1 résultat. Cela est
particulièrement vrai si votre base de données se trouve sur une machine différente qui est, disons, à 1-2
ms du réseau. Dans ce cas, l'émission de 100 requêtes en série a un coût minimum de 100-200 ms, même si MySQL
peut les satisfaire instantanément.
\ No newline at end of file
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment