Discussion :

[gb-ch]

Bonjour,

Depuis un script PHP j'ai une erreur "Maximum execution time of 30 seconds exceeded" très probableemnt en raison d'une requête SQL sur une base MySQL qui pourrait être (grandement) améliorée.

Voici ma requête qui s'exécute environ 30 fois (une fois par jour d'un mois donné).

Code :

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

1
2
3
 
SELECT pk_id FROM events_vk, plz_ptt
WHERE '2007-01-01' BETWEEN date_start AND GREATEST(date_end, date_start)

ici je demande les events qui ont lieu le 1er janvier 2007.

ou

Code :

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

1
2
3
4
5
 
SELECT pk_id FROM events_vk, plz_ptt 
WHERE '2007-01-01' BETWEEN date_start AND GREATEST(date_end, date_start) 
AND (events_vk.fk_plz_ptt = plz_ptt.ExchangeKey) 
AND (plz_ptt.PostalCode >= 1000) AND (plz_ptt.PostalCode <= 2000)

Dans ce cas deuxième cas tous les events qui ont lieu le 1er janvier 2007 et dont le code postal est compris entre 1000 et 2000.

La table events_vk gère des événements et j'utilise la table plz_ptt en jointure pour localiser les événements selon leur code postal. En effet la table plz_ptt contient 6723 lignes avec tous les codes postaux de Suisse.

Les deux tables sont reliées par la clé étrangère fk_plz_ptt de la table events_vk et la colonne (valeur unique) ExchangeKey de la table plz_ptt.

Comment améliorer ma requête pour pas que je dépasse ce délai attrbué à PHP? C'est donc une question d'optimisation de requête SQL, je sais...

Merci!

[qi130]

Les index sont déclarés sur les colonnes mentionnées ?

[Sivrît]

Il semble manquer une condition dans la première requête. S'il y a comme je le pense beaucoup de 'events_vk' ça peut faire très mal.

Indexer les dates pourrait aussi aider. Et si ça ne suffit pas il restera la possibilité de faire des indexes mixtes (comme (plz_ptt.ExchangeKey, plz_ptt.PostalCode) qui serrait pas mal).

"GREATEST(date_end, date_start)" huh... ça arrive souvent de finir avant d'avoir commencé ?

[gb-ch]

Il semble manquer une condition dans la première requête. S'il y a comme je le pense beaucoup de 'events_vk' ça peut faire très mal.

En fait, c'est la seconde requête qui pose problème, la première est rapide, n'agissant que sur une table.

Indexer les dates pourrait aussi aider. Et si ça ne suffit pas il restera la possibilité de faire des indexes mixtes (comme (plz_ptt.ExchangeKey, plz_ptt.PostalCode) qui serrait pas mal).

J'ai indexé aussi les dates, ça ne change rien... Que sont les indexes mixtes? C'est-à-dire indexer aussi les colonnes de jointures de la deuxième table? Déj fait...

"GREATEST(date_end, date_start)" huh... ça arrive souvent de finir avant d'avoir commencé ?

C'est que la base n'est pas "propre", certains date_end sont à 0000-00-00 alors je gère cela ainsi...

[Sivrît]

J'ai indexé aussi les dates, ça ne change rien... Que sont les indexes mixtes? C'est-à-dire indexer aussi les colonnes de jointures de la deuxième table? Déj fait...

"composé" serait peut-être plus approprié. Ce sont des indexes portant sur plusieurs colonnes. Comme un seul index peut servir par table, avoir deux indexes sur une table à laquelle deux critères sont appliqués dans une requête ne sert à rien car un seul sera utilisé (par exemple pour une jointure, l'inégalité étant ensuite testée sur tous les résultats).

Il faudrait voir ce que donne un 'EXPLAIN' pour savoir ce qui se passe. Sinon, quels sont exactement les indexes déjà créés ?