Optimisation requêtes mysql

[muelsaco]

Bonjour à tous!

J'ai une simple question à vous posez car je ne connais pas la réponse...
Pensez vous qu'il est mieux de se connecter à une base de données mysql en début de page, faire toutes les requetes puis refermer en fin de page? Ou au contraire fermé le plus possible la connection puis réouvrir par la suite en cas d'autres requêtes?

Merci d'avance!

 

[finstreet]

vaut mieux fermer en bas de page... ouvrir et fermer plusieurs fois sur la meme page, ca va plutot charger tes requetes.

par contre y'a des requetes à éviter... du genre des jointures à trois tables ou des INSERT SELECT... c le genre de trucs qui fait ramer

 

[petit-ourson]

Il vaut mieux ouvrir et fermé en début de page en le faisant une unique fois ;o)

 

[sonikbuzz]

[EDIT]
j'avais dit une bétise
[/EDIT]

 

[muelsaco]

A ok merci beaucoup!
Par contre j'ai remarqué un truc! Peut être que je me trompe mais bon...
Je fais une requête SELECT mais je n'affiche pas le contenu de suite. Je stocke toutes les informations dans des tableaux (à 2 dimensions forcémment) et ensuite l'affichage est nettement plus rapide!
Peut être que pendant le test le serveur était moins chargé... enfin qu'en pensez vous?

 

[sonikbuzz]

et ensuite l'affichage est nettement plus rapide!
Peut être que pendant le test le serveur était moins chargé... enfin qu'en pensez vous?

J'en doute, enfin tout depend du "nettement".
Le mieux c'est de se faire une petite fonction avec microtime() pour "bencher" les differentes requetes en boucle (entre 100 et 1000 fois) puis tu change l'ordre des requetes encore une boucle.

A la sortie ta fontion de donne la moyenne de chaques requetes.

 

[netsys]

J'avais fait un test en ouvrant une connexion au début et en la fermant à la fin et en ouvrant et fermant la connexion à chaque requete. Le temps d'execution était multiplié par 10 dans le second cas.

 

[sonikbuzz]

Pour en revenir a ta premiere question (j'ai édité mon 1er post) et comme le signale Netsys d'apres les tests que j'ai effectué se connecter à la base prend beaucoup de temp.
Donc je te conseille de l'ouvrir une fois avec mysql_connect et c'est tout : le link va se fermer en fin de script automatiquement.

 

[muelsaco]

Ok merci donc je vais laisser comme c'est car c'est comme çà que je fais. En plus çà m'évitera de tout changer ^^

 

[papa6]

Re:

Bonjour,

y'a des requetes à éviter... du genre des jointures à trois tables ou des INSERT SELECT... c le genre de trucs qui fait ramer

Ces infos m'intéressent : est-ce toujours d'actualité ? Et quand on dit ramer, ça veut dire des délais d'exécution multipliés par 1.5 ou 2, ou alors par 20 ou 100 (par ex.) ?
Parce qu'une requête à 3 tables, ce n'est pas grand chose, je comprendrais une requête sur 10 tables (et j'en fais :roll: ), mais 3 ou 4 ?

Merci pour l'info

 

[ortolojf]

Et puis...

Pour la sécurité...

C'est *mal* de mettre ses données d'identification à la bdd dans des variables globales dans un script php, puis de faire un include de ce script dans les scripts, en mettant ces variables comme globales.

Les variables étant globales, c'est très facile à un hacker, pour peu qu'il sache les noms des variables globales, d'incorporer dans un include à un script sur son serveur http le script distant, puis de faire tout bonnement des echo des variables globales...

Il suffit pour cela, que le hacker ait configuré son serveur Apache et php pour qu'ils acceptent les fopen et include avec des urls distantes. Malheur !

Pour bien sécuriser ses données d'authentification à une base de données, il est bon de mettre celles-ci comme variables locales à des fonctions de connexion et/ou déconnexion, elles-mêmes écrites dans le script php qui sera inclus dans les scripts du site.

Le top du top, est d'effacer ces variables avant les fins des fonctions, pour bien faire...

Les variables d'authentification étant locales, ne seront pas du tout visibles à l'extérieur des fonctions. De toute manière, on ne peut pas appeler une fonction située dans un script distant inclus dans un include...

...Plusieurs précautions valent mieux qu'une.

Celà dit, si le serveur est mal configuré, il y a théoriquement des possibilités, aux autres webmaster d'autres comptes ftp ( mal configurés ) d'accéder en lecture à vos scripts... Hébergeurs maudits à fuir comme la peste !

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[YoyoS]

Oh le Hs 8O. Tu fais tourner ortolojf ? :mrgreen:

 

[papa6]

En fait ma question concernait les requêtes aux imbrications multiples.

Mais là tu soulèves un autre sujet. En effet, il je fais appel à mes codes de connexion dans un fichier à part (include), et à la fin duquel je supprime mes données, sauf la connexion qui reste ouverte (unset($motdepasse, $moncompte, $etc)

Par contre, tu vas me faire peur : j'ai un site genre wiki de programmation en ligne (on n'écrit pas une encyclopédie, mais du code PHP) sur lequel n'importe qui peut écrire n'importe quoi et tester en direct. Mon principal soucis était le spam via mon site (il suffit de créer un fichier de mailing). Mais pour l'instant, je l'ai protégé par mot de passe que je distribue après un échange de mèls avec n'importe quel demandeur.
(pour mémoire : chefdesventes.org)

 

[YoyoS]

En fait ma question concernait les requêtes aux imbrications multiples.

Tu dois jouer avec les indexes sur les champs utilisés dans tes jointures pour accélérer tout ça. Après tu fais des tests, tu peux voir le temps que ça a pris en exécutant ta requête dans la console mysql> ou bien sur phpMyAdmin par exemple

 

[papa6]

Oui, merci, c'est ce que je fais.
Mais c'était le nombre de "3 tables" qui m'a fait beaucoup me questionner (comme je disais, il m'arrive de temps en temps de faire des jointures sur une dizaine de tables simultanément.)

En plus des index, il faut aussi utiliser, particularité de MySQL, les types "ENUM" et "SET" (mais par paresse je ne le fais pas et j'utilise une autre table avec jointure)

 

[Suede]

Au niveau connection, il vaut mieux se connecter, traiter, fermer et libérer la mémoire utiliser pour traiter les résultats aussi vite que possible.

mysql_free_result($resultat);