Discussion :

[arthuro45]

Bonsoir,

j'ai une requête qui souffre de lenteur excessive, je m'explique :

Je dois afficher plus de 500 lignes sur 24 colonnes avec sur chacune d'elle une liste déroulante dans un tableau html alimenté par une requête. cette requête est une vue alimentée par d'autres vues.
J'ai fais des vues pour me simplifier la vie dans mon application, mais concernant ce tableau je suis face un problème, il lui faut 22sec pour s'afficher !
autant dire que le client n'acceptera pas de subir cela.

Pensez-vous que le système des vues pour ce genre de grand tableau soit une bonne solution, ou puis-je obtenir de meilleurs performances en faisant une requête classique ?

[kedare]

Salut
On peux avoir un EXPLAIN de ta requête, la définition de ta vue, et ta requête ?
Merci

[SQLpro]

MySQL est connu pour être lent sur les vues.
Deux solutions : abandonner les vues ou passer à un vrai SGBDR comme PostGreSQL !

A +

[arthuro45]

Deux solutions : abandonner les vues ou passer à un vrai SGBDR comme PostGreSQL !

MySql ne serait pas un "vrai" SGBDR" ??

[SQLpro]

Pas vraiment, il lui manque encore bien des choses, dont la pire est l'impossibilité de faire des sauvegardes à chaud qui soient cohérentes.

Citons parmi les bug la fameuse date 0000/00/00 ! qui bien entendu n'existe pas... Bonjour l'intégrité et la cohérence des données

Citons parmi les manques SQL :
- pas de domaines
- pas de schémas SQL
- pas de requêtes récursives
- pas d'opérateur ensemblistes comme INTERSECT ou EXCEPT
- pas d'expression de tables (CTE)
- pas de fonctions de fenêtrage
- pas de groupage OLAP

Et pour l'indexation :
- les techniques d'indexation sont très limitées comme le sont les paramètres de création d'un index
- des index sur des colonnes calculées ou des expressions sont impossibles
- des index partiaux ou filtrès ne sont pas pris en charge
- les vues matérialisées ou indexées n'existent pas sous MySQL
- pas d'indexation possible des données XML ni SIG (spatial)

Pour le reste, voici le bilan que j'ai tiré il n'y a pas longtemps sur les retards de MySQL par rapport à la concurrence :

Gestion des threads très pauvre :
- pas de possibilité de donner la priorité à certains threads
- en principe : une connexion = un thread, mais cela ne fonctionne pas dans tous les cas
- aucun moyen d'être sûr qu'il y a X threads en activité
- trop de changement de contexte des threads
- sous utilisation du multi processeur, en particulier lorsque le serveur est chargé et à partir de 4 à 8 CPU

Gestion mémoire peu souple :
- pas de process unique d'allocation mémoire : chaque moteur à le sien !
- taille du buffer de tri non flexible (comme certains autres tampon mémoire)
- arrive à cours de mémoire lorsque le nombre de threads devient important
- utilise rarement toute la mémoire lorsque seulement quelques threads sont actif et qu'ils le pourraient

Gestion peu fiable des méta données
- MySQL n'a pas de méta données statiques (tables systèmes)
- les informations sont générées à la demande depuis les fichiers .frm
- les opérations de lecture des méta données ne sont pas transactionnelle (on peut donc obtenir un résultat faux).

Moteur de requête très limité
- exécution de certaines opérations strictement dépendante de l'écriture
- exécution parrallèle des requêtes très limitée
- gestion du cache des procédures peu évolué (la paramétrisation semble inexistante)
- parseur gourmand en ressources, spécialement pour des petites requêtes
- pas de récriture pour l'optimiseur
- utilisation outrancière de tables temporaires pour la résolution des requêtes

Exécution des procédures exécrable
- mauvaise gestion du cache des procédure à travers les différentes connexions
- pré verrouillage des tables
- aucun curseur scrollable (ils sont systématiquement matérialisés)
- le code des déclencheurs n'est pas partagé entre les différentes tables ouvertes
- aucune possibilité d'utiliser un langage externe

Réplication peu fiable
- la réplication ne peut être utilisé dans des contextes de haute sécurité car elle ne garnatie pas l'intégrité de la base
- pas de réplication synchrone
- pas d'outil pour vérifier la consistance des données répliquées

Convention de nommage très dépendante des moteurs
- du fait que les tables sont stockéed chacune dans un fichier différent, leurs noms peut être sensible ou non à la casse
- le portage d'un environnement à l'autre est difficile (Unix étant Case Sensitive, alors que ce n'est pas le cas de Windows ou MAC OS).

Gestion du stockage des données inexistantes
- pas de possibilité de définir la stratégie de gestion des espaces de stockage
- partitionnement des données plus cosmétique que technique

Gestion des privilèges et sécurité minimaliste
- sécurité des connexions et des utilisateurs très limitée
- pas de gestion des roles
- pas de privilèges possible au niveau schéma SQL
- pas de cryptage des données intégrée
- pas d'authentification possible par certificats

Sauvegardes très limitées
- il n'est pas possible de réaliser une sauvegarde à chaud en s'assurant que la base reste intègre
- la durée des sauvegardes et plus encore la durée de la restauration sont des opérations prohibitives pour de grosses bases.

Enfin, n'oublions pas que MySQL est payant, bien que MySQL AB a tenté de faire croire le contraire :
- soit paiement sous forme de code : vous ne payez pas la licence, mais mettez le code de votre appli à la disposition de tous
- soit paiement sous forme de licence

A +

[arthuro45]

mais mettez le code de votre appli à la disposition de tous

Peux-tu préciser ?

[SQLpro]

Peux-tu préciser ?

Extrait de :
http://www.mysql.com/about/legal/licensing/index.html
"
For Open Source Projects:
* If you are developing and distributing open source applications under the GPL License, then you are free to use MySQL under the GPL License
"
Ce qui se traduit par :
Si vous développez et distribuez vos applications sous forme open source sous licence GPL, alors vous avez le droit d'utiliser gratuitement MySQL.

A +

[arthuro45]

Effectivement c'est limpide. Malheureusement mon appli. est bien trop avancée pour migrer vers du Postgre SQL ou oracle...

Merci pour les infos.