Discussion :

[omelhor]

Bonjour,

J'ai beaucoup de requêtes qui prennent plus de 2 sec a la 1ère éxecution, à la 2ème c'est très rapide. Peut'on faire quelque chose pour accélérer ce type de requêtes ? J'ai mis des index dans mes champs de recherche, autre chose a faire ?

Merci


# Time: 211221 6:59:12
# User@Host: phpmyadmin[phpmyadmin] @ localhost []
# Thread_id: 1015285 Schema: live QC_hit: No
# Query_time: 2.174280 Lock_time: 0.000123 Rows_sent: 30 Rows_examined: 1228544
# Rows_affected: 0 Bytes_sent: 11968
SET timestamp=1640069952;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT title,author,timestamp,url,contents,image  FROM news WHERE  `author` NOT IN ('0AAAAAAAAAAAA')  AND timestamp < CURRENT_TIMESTAMP()  AND bdd_news LIKE 'live.copa_america_Venezuela' ORDER BY `timestamp` DESC LIMIT 0, 30;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE TABLE `news` (
	`ID` BIGINT(20) NOT NULL AUTO_INCREMENT,
	`title` VARCHAR(250) NOT NULL DEFAULT '' COLLATE 'utf8mb4_unicode_ci',
	`url` VARCHAR(350) NOT NULL COLLATE 'utf8mb4_unicode_ci',
	`timestamp` DATETIME NULL DEFAULT NULL,
	`contents` TEXT NOT NULL COLLATE 'utf8mb4_unicode_ci',
	`author` VARCHAR(100) NOT NULL DEFAULT '' COLLATE 'utf8mb4_unicode_ci',
	`author_news` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci',
	`bdd_news` VARCHAR(100) NOT NULL COLLATE 'utf8mb4_unicode_ci',
	`image` VARCHAR(350) NULL DEFAULT '' COLLATE 'utf8mb4_unicode_ci',
	`cat` VARCHAR(255) NOT NULL COLLATE 'utf8mb4_unicode_ci',
	`ts` TIMESTAMP NOT NULL DEFAULT current_timestamp(),
	`t` TINYINT(1) NOT NULL DEFAULT '0',
	PRIMARY KEY (`ID`) USING BTREE,
	UNIQUE INDEX `title_url_bdd_news` (`title`, `url`, `bdd_news`) USING BTREE,
	INDEX `idx_timestamp` (`timestamp`) USING BTREE,
	INDEX `idx_author` (`author`) USING BTREE,
	INDEX `bdd_news` (`bdd_news`) USING BTREE
)
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB
AUTO_INCREMENT=447145650
;

[isabelle.letrong]

Bonjour omelhor,

'1228544 rows examined', on sait pourquoi c'est long....

Questions :

• NOT IN ('0AAAAAAAAAAAA') à quoi cela correspond exactement ?
• LIKE 'live.copa_america_Venezuela'...Le LIKE, qui exclut l'emploi d'un index est-il bien nécessaire ?

[Artemus24]

Salut à tous.

J'ai beaucoup de requêtes qui prennent plus de 2 sec a la 1ère exécution, à la 2ème c'est très rapide.

C'est normal que la seconde exécution soit plus rapide que la première.
Dans la seconde exécution, MySql rechercher les résultats qu'il a stocké dans sa mémoire cache.

Peut-on faire quelque chose pour accélérer ce type de requêtes ?

Ajouter des index est une des solutions.
Comme l'indique isabelle.letrong, les deux conditions font que vous n'utilisez pas vos index.
J'ajouterai aussi la condition sur le timestamp.

Vos conditions sont non saegable, c'est-à-dire qu'ils n'utilisent pas les index.
Autrement dit, il y a un balayage de toutes vos lignes.
C'est la cause de la lenteur de l'exécution de votre requête.

Voici votre requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT   title,
         author,
         timestamp,
         url,
         contents,
         image
    FROM news
 
   WHERE `author` NOT IN ('0AAAAAAAAAAAA')
     AND timestamp < CURRENT_TIMESTAMP()
     AND bdd_news LIKE 'live.copa_america_Venezuela'
 
ORDER BY `timestamp` DESC
   LIMIT 0, 30;

1) à quoi vous sert de faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE `author` NOT IN ('0AAAAAAAAAAAA')

Que contient la colonne `bdd_news` ?
Avez-vous plusieurs fois dans votre table le libellé : "live.copa_america_Venezuela" ?
Je vous conseille d'externaliser cette colonne dans une autre table.
Ainsi le libellé sera associé à un identifiant numérique.
Et cet identifiant sera utilisé dans votre table "news" à la place du libellé.
Pourquoi ? Car les accès seront plus performant.

L'usage que vous faites de votre timestamp est bizarre.
A quoi cela vous sert de tester si la date est inférieure à la date du jour ?
Dois-je comprendre qu'il n'existe pas de date plus grande que la date du jour ?

Le test sur la colonne "author" est inutile.

Cordialement.
Artemus24.
@+

[escartefigue]

Bonjour,

Attention : l'opérateur LIKE n'exclut pas toujours l'utilisation d'index

WHERE ma_colonne like 'chaine%' est sargable* : les index présents sur la colonne ma_colonne sont potentiellement éligibles en fonction du facteur de filtrage
WHERE ma_colonne like '%chaine' n'est pas sargable, les index ne sont pas éligibles quoi qu'il arrive.

Pour les autres critères de restriction :

WHERE `author` NOT IN ('0AAAAAAAAAAAA') est non sargable, aucun index n'est éligible
AND `timestamp` < CURRENT_TIMESTAMP() est en théorie sargable si un index existe sur la colonne `timestamp', mais, comme il est très peu probable qu'il existe des valeurs de timestamp supérieures au timestamp courant, ce critère n'est dans les faits pas sargable non plus : aucun index ne sera éligible.

Par ailleurs, il est recommandé d'éviter les noms réservés SQL pour nommer les objets de la base de données.
TIMESTAMP par exemple est un mot reservé SQL, à éviter comme nom de colonne.

*SArgAble : Search Argument Able

[omelhor]

Salut à tous.


C'est normal que la seconde exécution soit plus rapide que la première.
Dans la seconde exécution, MySql rechercher les résultats qu'il a stocké dans sa mémoire cache.


Ajouter des index est une des solutions.
Comme l'indique isabelle.letrong, les deux conditions font que vous n'utilisez pas vos index.
J'ajouterai aussi la condition sur le timestamp.

Vos conditions sont non saegable, c'est-à-dire qu'ils n'utilisent pas les index.
Autrement dit, il y a un balayage de toutes vos lignes.
C'est la cause de la lenteur de l'exécution de votre requête.

Voici votre requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT   title,
         author,
         timestamp,
         url,
         contents,
         image
    FROM news
 
   WHERE `author` NOT IN ('0AAAAAAAAAAAA')
     AND timestamp < CURRENT_TIMESTAMP()
     AND bdd_news LIKE 'live.copa_america_Venezuela'
 
ORDER BY `timestamp` DESC
   LIMIT 0, 30;

1) à quoi vous sert de faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE `author` NOT IN ('0AAAAAAAAAAAA')

Que contient la colonne `bdd_news` ?
Avez-vous plusieurs fois dans votre table le libellé : "live.copa_america_Venezuela" ?
Je vous conseille d'externaliser cette colonne dans une autre table.
Ainsi le libellé sera associé à un identifiant numérique.
Et cet identifiant sera utilisé dans votre table "news" à la place du libellé.
Pourquoi ? Car les accès seront plus performant.

L'usage que vous faites de votre timestamp est bizarre.
A quoi cela vous sert de tester si la date est inférieure à la date du jour ?
Dois-je comprendre qu'il n'existe pas de date plus grande que la date du jour ?

Le test sur la colonne "author" est inutile.

Cordialement.
Artemus24.
@+

En fait dans la colonne "bdd_news" me sers a différencier une "nom de joueur de football" par exemple.
Et pour 1 "bdd_news" , je peux avoir plusieurs milliers de news ,ce qui explique la volumétrie de la table

Je vais penser a externaliser cette colonne dans une autre table, merci pour le conseil

J'ai besoin du test sur la colonne "author", la j'ai mis '0AAAAAAAAAAAA' comme exemple, mais suivant si l'on est sur mobile ou desktop, je peux décider d'afficher un/plusieurs "author" ou pas. Parfois pour une catégorie je n'affiche pas un "author"
Je vais le gérer autrement, directement dans le php, est exclure les auteurs via une boucle


je clos le sujet, merci beaucoup