IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MySQL Discussion :

Un problème de tri ! [MySQL-5.6]


Sujet :

MySQL

  1. #21
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 966
    Points : 30 778
    Points
    30 778
    Billets dans le blog
    16
    Par défaut
    Bonsoir Artemus24,


    Citation Envoyé par Artemus24 Voir le message
    La théorie, c'est bien, mais pour les théoriciens.
    Et c’est très bien aussi pour les gens qui comme moi ont beaucoup crapahuté dans les bases de données. Rassurez-vous, j’ai longtemps fait le DBA DB2 avec le « 3R » pour devise (Reorg, Runstats, Rebind) sans oublier le précieux EXPLAIN qui manquait cruellement dans DB2 V1 (1984) et sans lequel il n’était pas bien prudent de faire de la production (j’ai attendu la V1R2 (1986) pour enfin faire du tuning autrement qu’en aveugle). Cela dit, la maîtrise de la théorie relationnelle m’a permis de rattraper des gros projets qui partaient en quenouille, d’empêcher d’autres DBA de faire des bêtises (voyez l’exemple de la banque d'une ville méridionale où il fait bon vivre...)

    Outre le « 3R », je pense qu’il faut avoir à l’esprit ce que chantait le poète (merci, Georges !) :

    G. Brassens :

    « Sans technique, un don n’est rien qu’un’ sal’ manie... »
    Bref, théorie et technique ne sont pas forcément synonymes, mais en tout cas complémentaires et d'une grande aide...



    Citation Envoyé par Artemus24 Voir le message
    Quand on est face à un problème, la norme on s'en fout.
    Parlez-vous de la norme SQL ? de la normalisation en nième forme normale ? d’autre chose ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  2. #22
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Citation Envoyé par Artemus24
    Si j'ai créé ce sujet, c'est que je pensais, à tort, que le fonctionnement de MySql se faisait à l'identique de ce que je connaissais de DB2.
    Je dis cela en pensant que MySql suivait la norme SQL. Mea culpa !
    Il ne la suit en effet pas, mais ça n'a rien a voir avec le sujet de la discussion qui parle des index. Or, les index n'ont rien à voir avec la norme SQL qui ne se préoccupe pas de l'aspect physique, mais qui reste au niveau logique. Vous ne trouverez pas un mot au sujet des index dans la norme, et chaque éditeur est libre de les implémenter ou non, et surtout comme il l'entend.

    Citation Envoyé par Artemus24
    Ici, il utilise l'indexe 'clef2' alors qu'il aurait dû utiliser la 'primary key'.
    Non ! il aurait . ça fait toute la différence.
    Vous indiquez au SGBDR (par une requête) ce que vous voulez, libre à lui de trouver comme il l'entend la façon la plus efficace d'y répondre.
    Les hint ne sont pas fait pour obtenir un ordre précis, mais pour tirer occasionnellement le moteur d'un mauvais pas lorsqu'il fait de mauvaises estimations (au sens performances, pas au sens du tri que vous voulez obtenir).

    Citation Envoyé par Artemus24 Voir le message
    Pourquoi aléatoire ? Donc à bien te comprendre, tu fais un "select *" et cinq minutes après, tu en refais un autre, et tu n'as pas le même tri.
    Allons allons, ne dit pas n'importe quoi.
    Ce n'est pas n'importe quoi !!
    Je l'ai déjà observé sous SQL Server : une requête qui renvoyait une fois sur deux un ordre puis un autre.
    J'en conviens, ça n'arrive pas tout le temps (surtout avec MySQL qui ne connait pas le parallélisme), mais ça peut arriver.


    Citation Envoyé par Artemus24
    Ce qui signifie que MySql va chercher les lignes et les mettre dans l'ordre selon la 'primary key'.
    Là encore, vous n'avez pas compris : MySQL va chercher bien les lignes mais n'effectuera aucun tri : il les récupérere naturellement (le plus souvent, mais pas forcément) selon l'ordre de la PK dans votre exemple.

  3. #23
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    a) j'ai quatre possibilités pour influence le choix de mysql sur le 'full scan'. Est-ce qu'il existe d'autres possibilités d'écritures ?
    Comme déjà dit, dans votre cas, puisque vous voulez un tri, utilisez ORDER BY.

    Faites donc le test suivant sur la requête qui vous pose souci en utilisant l'index sur col2 : ajouter un ORDER BY col1.
    Vous remarquerez que MySQL n'utilisera plus cet index idx2, mais passera sur l'index de la PK.

    En effet, sans ORDER BY, les deux index couvrent la requêtes, et ils seront tous les deux aussi efficaces.
    En ajoutant la clause de tri, l'index sur la clef primaire prend un avantage, car en plus de couvrir la requête, il répond également au tri demandé. MySQL va donc l'utiliser plutôt que idx2, ce qui lui évitera un tri.
    En l'occurence, la clause ORDER BY n'aura donc aucun surcout (puisqu'en fait, aucun tri ne sera effectué). Il est donc bien mieux qu'un hint,puisqu'en plus d'avoir l'effet escompté sans surcout, il inclus clairement dans votre requête ce que vous attendez d'elle, ce qui sera bien mieux en maintenance (pensez a ceux qui pourraient reprendre votre requête... comment interpréteront-ils le hint ?).

  4. #24
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 966
    Points : 30 778
    Points
    30 778
    Billets dans le blog
    16
    Par défaut A propos de ORDER BY
    Bonsoir,


    A propos de ORDER BY...

    Si vous vous vous plongez dans le 1er article [Boyce1974], publié en 1974 sur le langage SQL (SEQUEL à l’époque, qui a perdu ses voyelles pour éviter de possibles problèmes de copyright), vous noterez qu’ORDER BY en est absent. C’est normal, fruit des cogitations de deux chercheurs du laboratoire de recherche d’IBM (San Jose), Chamberlin et Boyce(RIP), SEQUEL n’était qu’un prototype visant à montrer qu’en deux lignes et une minute, on en faisait autant qu’avec un programme de 500 lignes et une journée d’effort (au moins ! j’ai donné...) de programmation de l’époque (avec IMS DL/1, IDMS, IDS2 et autres poids lourds). Manipuler des ensembles, par définition non ordonnés, quoi de plus naturel pour des mathématiciens ? ils n’auraient pas été émus outre mesure d’entendre Monsieur Jourdain déclamer :

    « Me font vos yeux beaux mourir, belle Marquise, d’amour ! »

    Peu leur importait l’ordre des éléments affichés à l’écran ou imprimés. Mais en 1976, dans la version 2 de SEQUEL [Chamberlin1976], ORDER BY entre en scène. Je cite (le soulignement des mots et autres fioritures sont de mon fait) :

    The result of a query is returned in system-determined order unless the user requests an ordering, as shown in Q5.

    Q5. List the employee number, name, and salary of employees in Dept. 50, in order of employee number.

    SELECT EMPNO,NAME,SAL
    FROM EMP
    WHERE DNO = 50
    ORDER BY EMPNO

    Une première !

    Visiblement, on sort du cadre de la recherche pure, on commence à s’intéresser aux souhaits des utilisateurs ayant joué les cobayes et dont on a étudié les réactions, en conséquence de quoi des éléments n’ayant rien à voir avec la théorie relationnelle viennent « compléter » le langage, et ça n'est pas fini...


    Cela dit, cette requête Q5 a 40 ans, mais en l’état demeure opérationnelle...

    _____________________________________

    Références

    [Boyce1974] R. F. Boyce, D. D. Chamberlin. SEQUEL: A structured English query language.

    [Chamberlin1976] D. D. Chamberlin, M.M. Astrahan, et al. SEQUEL 2: A Unified Approach to Data Definition, Manipulation, and Control. IBM Journal of Research and Development, vol. 20, n° 6, novembre 1976.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #25
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Ce que j'essaye de faire, c'est d'une part comprendre les différences avec DB2 et d'autre part de faire de l'optimisation.
    @+
    Du point de vue de la séquence selon laquelle les enregistrements sont restitués en l'absence d'order by, vous aurez donc compris qu'il n'y en a pas
    Que ce soit DB2 for Z/OS ou ses pseudo-clones micro ou AS/400

  6. #26
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Je dis cela en pensant que MySql suivait la norme SQL. Mea culpa !
    La norme SQL se fout royalement de l'optimisation propre à chaque éditeur. En cette matière MySQL est certainement doté du plus mauvais optimiseur qui soit...

    Encore une fois il n'existe JAMAIS sur aucun SGBDR d'ordre par défaut et pensez le contraire en évitant un ORDER BY est imbécile et suicidaire !

    Vous ne méritez pas votre statut de membre éclairé, et je pense que je vais demander aux administrateur de developpez.com de vous rétrograder !
    Passe encore que vous disiez des inepties, mais persister dans votre ignorance et repousser les conseils de gens avisés est stupide et confine à l'imbécilité !
    "errare humanum est, perseverare diabolicum"
    Bref, seriez vous un suppôt de Satan ?

    Il y a quelques années j'ai montré les méfaits de cette croyance avec SQL Server. Bien des gens avaient fait des vues avec SELECT TOP 100 PERCENT WITH TIES ... ORDER BY ... . À partir de la version 2008 ce tri ne s'effectuait plus du tout quelques soit la manière de lancer la vue ! C'est justement le fait de l'optimiseur, car une vue ne doit jamais en aucun cas avoir un ORDER BY ce que l'imbécile clause TOP permettait !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #27
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 959
    Points
    18 959
    Par défaut
    Salut à tous.

    Citation Envoyé par fsmrel
    j’ai attendu la V1R2 (1986) pour enfin faire du tuning autrement qu’en aveugle
    A cette époque là, j'étais encore ingénieur d'étude et je faisais beaucoup de développement cobol / jcl.

    Citation Envoyé par fsmrel
    voyez l’exemple de la banque d'une ville méridionale où il fait bon vivre...
    Je l'ai lu. Très intéressant comme expérience ! Et c'est pourquoi, il ne faut pas laisser n'importe qui faire n'importe quoi.
    J'ai déjà été confronté à des problèmes similaire, comme la fois où un pseudo DBA croyait bien faire et dégradait les performances de l'ensemble d'un projet, juste pour améliorer la performance d'une lourde requête.

    Citation Envoyé par fsmrel
    Bref, théorie et technique ne sont pas forcément synonymes, mais en tout cas complémentaires et d'une grande aide...
    Je ne confronte pas théorie d'un coté et technique de l'autre. Ce sont juste des aides pour parvenir au but recherché.
    Quand je dis que je suis pragmatique, je veux signifier que je ne prends jamais rien pour argent comptant.
    De ce fait, je vérifie et j'expérimente toujours avant de faire une modification. Et même après la modification, je vérifie l'impacte que cela a sur le reste du projet.
    Mon credo reste toujours le juste équilibre entre d'une part le respect de la normalisation et d'autre part le cout en volumétrie et en temps d'exécution, autrement dit en performance.

    Citation Envoyé par fsmrel
    Parlez-vous de la norme SQL ? de la normalisation en nième forme normale ? d’autre chose ?
    Oui, manque de précision de ma part. Je ne parle pas des formes normales que je respecte, mais des normes SQL.
    Quand on travaille avec un SGBD, la norme SQL n'est pas toujours respectée et seul le fonctionnement du SGBD fait preuve de foi. Donc on fait avec !
    Ce qui signifie que d'un SGBD (DB2) à l'autre (MySql), on peut se retrouver avec des normes différentes, dues à des évolutions différentes dans le temps.
    Et je n'aime pas trop que l'on dise du mal de MySql car certains membres ayant fait l'usage d'un SGBD plus respectueux des normes SQL se retrouvent en panne d'imagination pour trouver la solution sous MySql.

    Citation Envoyé par aieeeuuuuu
    Or, les index n'ont rien à voir avec la norme SQL qui ne se préoccupe pas de l'aspect physique, mais qui reste au niveau logique.
    A vrai dire, je ne connais pas la norme SQL, mais juste la façon dont elle est appliquée dans DB2. C'est DB2 que je connais et non la norme SQL.
    Je recherchais à l'identique ce que je connaissais de DB2 mais dans MySql. Voilà pour les explications.

    Citation Envoyé par aieeeuuuuu
    Non ! il aurait pû. ça fait toute la différence.
    Je comprends ce que vous me dites, mais quand on fait un "select * from test" par exemple, je m'attends à obtenir un 'full scan' de ma table triée selon l'ordre de ma "primary key' et non sur un autre indexe. C'est pas logique !
    Mais quand je compare le résultat produit par cette requête, juste en changeant "InnoDB' par "Memory' ou encore 'MyIsam', je suis surpris de ne pas obtenir la même chose.
    C'est en cela que je dis qu'il y a un bug de fonctionnement.

    Citation Envoyé par aieeeuuuuu
    Les hint ne sont pas fait pour obtenir un ordre précis, mais pour tirer occasionnellement le moteur d'un mauvais pas lorsqu'il fait de mauvaises estimations (au sens performances, pas au sens du tri que vous voulez obtenir).
    J'ai bien compris que la solution est de faire "select * from test order by clef", juste pour influencer l'optimiseur à faire l'usage de la 'primary key'.
    J'ai testé autre chose (les hints) afin de voir ce que je pouvais obtenir, mais ce n'est pas la solution à envisager, enfin dans cet exemple là.

    Citation Envoyé par aieeeuuuuu
    Ce n'est pas n'importe quoi !!
    Je l'ai déjà observé sous SQL Server : une requête qui renvoyait une fois sur deux un ordre puis un autre.
    J'en conviens, ça n'arrive pas tout le temps (surtout avec MySQL qui ne connait pas le parallélisme), mais ça peut arriver.
    J'en conviens que cela ne m'est jamais encore arrivé et cela peut surprendre d'avoir de l'aléatoire dans le fonctionnement d'un SGBD.
    Il se peut que l'on rencontre des problèmes forts différents entre le gros système et la micro.

    Citation Envoyé par aieeeuuuuu
    Citation Envoyé par Artemus24
    Ce qui signifie que MySql va chercher les lignes et les mettre dans l'ordre selon la 'primary key'.
    Là encore, vous n'avez pas compris : MySQL va chercher bien les lignes mais n'effectuera aucun tri : il les récupérere naturellement (le plus souvent, mais pas forcément) selon l'ordre de la PK dans votre exemple.
    Je ne parle pas du tri, dans le sens de l'usage du 'filesort', mais de l'ordre apparent à l'affichage qu'il faut distinguer de l'ordre réel dans le 'table space'.
    Si vous faites un vidage de votre 'table space' par un utilitaire, vous devriez observer que les lignes ne sont pas stockées dans l'ordre en fonction de votre 'primary key' mais en fonction du 'rowid'. Je nomme cela l'ordre réel.
    Si maintenant vous faites un 'select * from test', ce n'est pas l'ordre réel que vous obtenez, mais l'ordre apparent selon l'indexe qui est en usage (voir l'explain) à cet instant.
    La 'primary key' est un indexe comme les autre. Alors à quoi sert la primary key et pourquoi faire une distinction avec les autre indexes ?
    Elle sert à faire le lien entre l'emplacement réel de la ligne dans le 'table space', et l'ordre apparent selon cette 'primary key'.
    Et c'est pourquoi, quand on crée un indexe, celui-ci fait toujours référence à la primary key.

    Si à chaque insertion, modification ou suppression, MySql se réorganiserait alors l'ordre réel serait toujours en conformité avec l'ordre apparent de la 'primary key'.
    Et de ce fait, une réorganisation de la table et de surcroit du 'table space' ne servirait à rien ! Or il n'y a pas de réorganisation automatique.
    Il faut comprendre que les lignes dans un 'table space' sont dans un ordre quelconque, disons aléatoire.
    Mais quand on fait un 'select', l'ordre apparent est toujours selon l'ordre soit de la 'primary key', soit d'un l'indexe.
    S'il n'y a pas de 'primary key' ou d'indexe alors l'ordre apparent est en conformité avec l'ordre réel.

    Je pense que vous ne m'avez pas compris sur ce sujet, où d'une part je ne parle pas de tri, mais d'ordre (réel et apparent) et d'autre part la façon dont le SGBD s'organise d'une manière aléatoire pour stocker les lignes dans le 'table space'.

    Si je me suis trompé dans mes explications, donnez moi un exemple qui prouve que j'ai tort.
    D'ailleurs, connaissez vous un utilitaire qui fasse le vidage "physique" d'un 'table space' ? Je ne parle pas, bien sûr, de mysqldump.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  8. #28
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 959
    Points
    18 959
    Par défaut
    Salut à tous.

    Citation Envoyé par aieeeuuuuu
    Comme déjà dit, dans votre cas, puisque vous voulez un tri, utilisez ORDER BY.

    Faites donc le test suivant sur la requête qui vous pose souci en utilisant l'index sur col2 : ajouter un ORDER BY col1.
    Vous remarquerez que MySQL n'utilisera plus cet index idx2, mais passera sur l'index de la PK.
    Je vais détailler ma pensé à ce sujet.

    1) comme je l'ai dit dans un message précédent, quand je fais un "select * from test", je m'attendais à l'ordre apparent selon la 'primary key'.
    D'où le test que j'ai fait en passant de 'innodb' à 'memory' ou à 'myisam'. et je constate que 'innodb' ne fonctionne pas comment les deux autres moteurs.
    Pourquoi cette différence de fonctionnement ?

    2) oui, j'ai bien compris que la solution donnée par escartefigue (que je remercie au passage), consiste à mettre 'order by clef' sur la requête 'select * from test', non pas pour trier le résultat, mais juste demander à mysql de choisir le bon indexe, entre autre la 'primary key'.
    Et ma question qui demeure sans réponse actuellement, est la suivante : est-ce la seule solution possible à mon problème ?
    N'y a-t-il pas un quelconque paramétrage à mettre en place dans le fichier 'my.ini' pour ne pas avoir continuellement ce problème, à savoir écrire ma requête ainsi "select * from test order by clef" pour obtenir l'ordre apparent sur la "primary key" ?

    3) pourquoi mysql prend-il la décision de sélectionner le premier indexe, autre que la 'primary key' ?
    C'est ça qui me pose problème ! Bon, si MySql procède ainsi, je ferai avec.

    Citation Envoyé par aieeeuuuuu
    Il est donc bien mieux qu'un hint, puisqu'en plus d'avoir l'effet escompté sans surcout, il inclus clairement dans votre requête ce que vous attendez d'elle ...
    4) J'ai fait des tas de tests et le 'hint' ne fonctionne pas toujours.

    a) Quand j'ai juste une 'primary key' dans ma table, j'obtiens le bon résultat :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    --------------
    explain select * from test1
    --------------
     
    +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+
    | id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
    +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+
    |  1 | SIMPLE      | test1 | index | NULL          | PRIMARY | 4       | NULL |    9 | Using index |
    +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+
    b) Toujours sur la même table, si je lui demande de ne pas faire l'usage de la 'primary key', voici ce que j'obtiens :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    --------------
    explain select * from test1 IGNORE INDEX (PRIMARY)
    --------------
     
    +----+-------------+-------+------+---------------+------+---------+------+------+-------+
    | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra |
    +----+-------------+-------+------+---------------+------+---------+------+------+-------+
    |  1 | SIMPLE      | test1 | ALL  | NULL          | NULL | NULL    | NULL |    9 | NULL  |
    +----+-------------+-------+------+---------------+------+---------+------+------+-------+
    A priori, l'optimiseur n'indique aucun indexe. Je ne sais quoi penser de ce résultat.

    c) Toujours dans ma table, j'insère des lignes, puis ensuite, j'en supprime quelques unes et je les ré-insère.
    C'est juste pour avoir un jeu d'essai un peu plus réel.

    d) je fais le vidage de ma table selon le cas a) et le vidage de ma table selon le cas b), et j'obtiens le même résultat. C'est normal !
    Mais alors pourquoi par l'explain, j'obtiens deux résultats différents, dont l'un voudrait signer que je passe par la 'primary key' et l'autre pas aucun indexe ?
    Dans le cas b), j'aurai dû (???) obtenir l'ordre réel et l'ordre apparent.

    Alors je conclu que le résultat de l'explain, pour le cas a) et le cas b) sont totalement similaire.

    Est-ce que je fais une erreur d'interprétation ?

    Citation Envoyé par fsmrel
    The result of a query is returned in system-determined order unless the user requests an ordering, as shown in Q5.
    A bien comprendre votre exemple, jadis, on avait encore l'ordre réel de stockage, si on ne précisait pas la clause 'order by'.
    Alors que maintenant, on n'a plus du tout l'ordre réel, mais juste l'ordre apparent.

    Je comprends ! Mais c'est quand même différent de la sélection de tel ou tel indexe par l'optimiseur de MySql, non ?

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  9. #29
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 959
    Points
    18 959
    Par défaut
    Salut sqlpro.

    A chaque fois que vous intervenez, c'est juste pour critiquer !

    Citation Envoyé par sqlpro
    il n'existe JAMAIS sur aucun SGBDR d'ordre par défaut
    Et qu'est-ce que vous entendez par "ordre par défaut" ? Votre phrase ne veut rien dire du tout !
    Dois-je comprendre qu'à chaque fois que je fais un 'select', je n'obtiens jamais le même ordre apparent des lignes ?

    Selon moi, vous avez une conception théorique des bases de données et vous ne vous intéressez jamais au contrainte physique, qui nécessite justement l'optimisation de la performance.

    Citation Envoyé par sqlpro
    Il y a quelques années j'ai montré les méfaits de cette croyance avec SQL Server
    Qu'est-ce que j'ai à foutre de SQL Server. Nous sommes dans le forum consacré à MySql alors essayez de ne pas être hors sujet.

    Donnez-moi un exemple concret sous mysql démontrant vos affirmations !
    Si vous ne vous pliez pas à ces exigences, vos paroles sont vaines et reflètes juste votre arrogance !

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  10. #30
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Il faut comprendre que les lignes dans un 'table space' sont dans un ordre quelconque, disons aléatoire.
    [...]
    Je pense que vous ne m'avez pas compris sur ce sujet, où d'une part je ne parle pas de tri, mais d'ordre (réel et apparent) et d'autre part la façon dont le SGBD s'organise d'une manière aléatoire pour stocker les lignes dans le 'table space'.
    En fait il n'y a rien d'aléatoire... Un processus aléatoire est, selon le Larousse : "soumis au hasard, dont le résultat est incertain". En matière de SGBDR le résultat est certain et déterministe. Il est néanmoins donné dans un ordre ARBITRAIRE !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  11. #31
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 959
    Points
    18 959
    Par défaut
    Salut sqlpro.

    Citation Envoyé par escartefigue
    Quelque soit le SGBD, l'absence d'une clause order by, rend la séquence des enregistrements restitués par le select aléatoire
    Au lieu de me faire de la rhétorique de bas étage, Monsieur SQLPRO, c'est plutôt à escartefigue que vous auriez dû vous adressez, car c'est lui qui a introduit le mot aléatoire dans ce sujet.

    Définition du mot "arbitraire" :
    Qui résulte d'un libre choix et ne répond à aucune nécessité logique
    Vous vous trompez même dans l'usage du mot dont vous désirez illustrer vos propos.
    Ce n'est pas un "libre choix", mais une contrainte par la nécessite de l'organisation physique sur laquelle repose votre base de données.
    Arrêter de faire de la masturbation intellectuelle à tout bout de champs et essayez de répondre, sans condescendance, aux questions posées si vous en êtes capable. Mais ça, j'en doute.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  12. #32
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    A bien comprendre votre exemple, jadis, on avait encore l'ordre réel de stockage, si on ne précisait pas la clause 'order by'.
    Alors que maintenant, on n'a plus du tout l'ordre réel, mais juste l'ordre apparent.
    Encore une fois vous supposez des choses qui n'existent pas; Ni maintenant ni avant les SGBDR restituait les données dans un ordre quelconque prédéfini, par exemple l'ordre de stockage.
    Deux exemple pour vous démontrer le contraire :
    1) une partie des données de la table est en mémoire : le système va sans doute restituer en première les données en RAM puis en parallèle monter les données du disque en RAM, pour enfin restituer la queue.
    2) pour les SGBDR faisant du parallélisme au niveau des IO comme du cache, l'ordre de présentation des lignes sera arbitraire, car ce sera le premier thread qui présentera ses données en premier pour l’utilisateur..

    Bref, vous avez encore bien du chemin à faire pour comprendre ce que vous n'avez pas compris.
    Votre faiblesse vient du fait que vous ne maîtrisez pas la théorie, comme vous l'a fait remarquer FMSREL, alors vous inventez votre propre logique...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  13. #33
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Vous vous trompez même dans l'usage du mot dont vous désirez illustrer vos propos.
    Ce n'est pas un "libre choix", mais une contrainte par la nécessite de l'organisation physique sur laquelle repose votre base de données.
    Encore une fois non ! Vous n'avez rien compris ! C'est bien le libre choix qu'effectue l'optimiseur ! Libre choix d'utiliser tel ou tel index, ou la table. Libre choix encore d'effectuer une lecture série ou en parallèle. Vous, vous n'avez aucun choix possible que de lancer des requêtes qui sont de simples demandes et non une suite d'instruction à réaliser dans le strict respect de l'ordre des éléments !!!

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  14. #34
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Dois-je comprendre qu'à chaque fois que je fais un 'select', je n'obtiens jamais le même ordre apparent des lignes ?
    ENFIN !!! Hourra !!! vous commencez à percevoir les choses... Il serait temps !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  15. #35
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    2) oui, j'ai bien compris que la solution donnée par escartefigue (que je remercie au passage), consiste à mettre 'order by clef' sur la requête 'select * from test', non pas pour trier le résultat, mais juste demander à mysql de choisir le bon indexe, entre autre la 'primary key'.
    C'est gentil de me remercier, mais relisez tous mes posts ci-dessus : je n'ai jamais écrit une énormité pareille !
    (j'ai moi même relu mes posts car j'ai failli faire un arrêt cardiaque )
    C'est tout le contraire : mettre un order by c'est pour trier, rien d'autre

  16. #36
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    En effet, vous devez confondre avec mon post #23.

    Mais je parlais bien de mettre un ORDER BY pour avoir un tri et vous faisais remarquer que de fait il utilise un autre index. je disais donc que c'était bien mieux qu'un HINT.
    En aucun cas je ne vous proposais cette solution pour le forcer à utiliser un index quelconque.

  17. #37
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 966
    Points : 30 778
    Points
    30 778
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par Artemus24 Voir le message
    La 'primary key' est un indexe comme les autres
    Hum... J’ai rappelé ici que le concept de clé primaire a été inventé par un mathématicien, Ted Cod, dans le cadre de la théorie relationnelle, laquelle ressortit aux mathématiques appliquées.

    J’ai aussi rappelé que l’index intervient dans la soute, au niveau de la tuyauterie et n’a donc rien à voir avec la clé primaire, ça n’est qu’un fichier dont les plombiers ont eu l’idée de se servir pour héberger les valeurs prises par les attributs d’une table, notamment ceux qui composent une clé primaire et, physiquement, en garantir l’unicité.



    Citation Envoyé par Artemus24 Voir le message
    A vrai dire, je ne connais pas la norme SQL
    C’est l’occasion d’en prendre connaissance. Pour moins de 10 euros (port compris) vous pouvez acquérir l’ouvrage de Peter Gulutzan, SQL-99 Complete, Really, mais n’y cherchez pas l’instruction CREATE INDEX ! La plomberie ne fait évidemment pas partie de la norme.





    Mais l’ouvrage de Gulutzan fait plus de 1000 pages... Comme introduction à la norme, l’ouvrage de Date et Darwen (qui a longtemps représenté le Royaume uni dans le comité ISO SQL) est le plus indiqué (500 pages quand même) : A Guide to SQL Standard (4th Edition), pour environ 5 euros ! (via AbeBooks.com).

    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  18. #38
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    ...J’ai aussi rappelé que l’index intervient dans la soute, au niveau de la tuyauterie et n’a donc rien à voir avec la clé primaire...
    Je rajouterais même qu'il n'est null besoin d'index pour qu'une clef primaire existe et soit opérationnelle. Le seul inconvénient sans index sous-jacent, c'est que les insertions et modifications seront lentes :
    1) il faut verrouiller la table au niveau d'isolation SERIALIZABLE pour chaque insertion
    2) pendant que la table est verrouillée, il faut vérifier par balayage que la clef n'existe pas déjà et si non, insérer puis libérer le verrou
    C’est l’occasion d’en prendre connaissance. Pour moins de 10 euros (port compris) vous pouvez acquérir l’ouvrage de Peter Gulutzan, ... Mais l’ouvrage de Gulutzan fait plus de 1000 pages... Comme introduction à la norme, l’ouvrage de Date et Darwen (qui a longtemps représenté le Royaume uni dans le comité ISO SQL) est le plus indiqué (500 pages quand même)
    Il y a mieux... Les deux tomes de Jim Melton, qui est le rapporteur de la norme SQL au commité ISO :

    http://www.amazon.fr//dp/1558604561


    http://www.amazon.fr/dp/1558606777

    Sinon, à la source, les documents de l'ISO :
    Framework :
    http://www.iso.org/iso/fr/home/store...csnumber=53681
    Foundations :
    http://www.iso.org/iso/fr/home/store...csnumber=53682

    Comptez quand même quelque milliers de pages !!!

    Bonne lecture

    A +

    PS : les livres de l'ISO furent ma tasse de thé pour mon ouvrage sur SQL aux éditions Pearson.
    Bref si vous voulez quelque chose,de compréhensible, facile à lire, normatif et en français...


    http://www.amazon.fr//dp/2744076309

    Et il y a même un chapitre (10) sur les index, qui commence par ces termes :
    "
    Absolument fondamentale, l’indexation des bases de données est souvent négligée. Avec la mise en place des contraintes, l’indexation fait qu’une base de données se différencie notablement de tout autre système de stockage des données, comme les fichiers, aussi organisés soient-ils. Le but d’un index est d’accélérer certaines recherches de façon à diminuer de manière très sensible la durée des traitements. Mais une indexation mal organisée recèle de nombreux pièges. C’est pourquoi la mise en place des index se doit d’être faite en pleine connaissance de cause et avec circonspection. Pour cela une triple connaissance est nécessaire : celle du modèle de la base de données, celle de l’utilisation des données par les applications et celle propre à la structure des index et aux techniques de l’indexation. C’est ce à quoi tente de répondre ce chapitre.
    "
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  19. #39
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 959
    Points
    18 959
    Par défaut
    Salut à tous.

    On s'est bien écarté du sujet de base.

    Citation Envoyé par SQLPRO
    Encore une fois vous supposez des choses qui n'existent pas; Ni maintenant ni avant les SGBDR restituait les données dans un ordre quelconque prédéfini, par exemple l'ordre de stockage.
    Cette question ne s'adressait pas à vous, mais à fsmrel. Et ce n'est pas parce que vous êtes encore très jeune qu'il faut croire que les bases de données sont nées en même temps que vous.

    Citation Envoyé par SQLPRO
    Visiblement, on sort du cadre de la recherche pure, on commence à s’intéresser aux souhaits des utilisateurs ayant joué les cobayes et dont on a étudié les réactions, en conséquence de quoi des éléments n’ayant rien à voir avec la théorie relationnelle viennent « compléter » le langage, et ça n'est pas fini...
    Ma question était de savoir si à un moment donné, dans DB2, un 'select *' se faisait dans l'ordre de stockage et non selon la clef primaire ?
    Ou bien, je n'ai pas compris l'exemple que vous avez voulu illustrer par l'introduction du 'order by'.
    Hormis que ce soit à la demande des utilisateurs, et non un choix issue de la théorie, je ne comprends même pas pourquoi la théorie a fait une impasse sur cet clause.

    Citation Envoyé par SQLPRO
    1) il faut verrouiller la table au niveau d'isolation SERIALIZABLE pour chaque insertion
    Je n'ai pas attendu sur vous pour le faire.

    Citation Envoyé par SQLPRO
    Deux exemple pour vous démontrer le contraire :
    1) une partie des données de la table est en mémoire : le système va sans doute restituer en première les données en RAM puis en parallèle monter les données du disque en RAM, pour enfin restituer la queue.
    2) pour les SGBDR faisant du parallélisme au niveau des IO comme du cache, l'ordre de présentation des lignes sera arbitraire, car ce sera le premier thread qui présentera ses données en premier pour l’utilisateur..
    Je ne me retrouve ni dans le cas 1) ni dans le cas 2) ! Pourquoi ?
    Pour le cas 1) je n'ai pas une volumétrie qui fasse que je puisse à un moment donné me retrouver dans ce cas de figure.
    Ensuite, je suis en ce moment dans des tests d'optimisations et de ce fait, j'ai désactivé (temporairement) l'accès aux buffers afin d'avoir le vrai temps d'exécution de mes requêtes.
    Pour le cas 2), je n'ai rien vu dans le paramétrage de 'MY.INI' quelque chose qui m'indiquerait que je fais du parallélisme.
    De plus, je travaille sur un ordinateur portable HP Compas 6830s qui est dual core.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Processeur	Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz, 2401*MHz, 2 cœur(s), 2 processeur(s) logique(s)
    Avant de généraliser comme vous le faites, renseignez vous sur la configuration du matériel et sur le travail que j'effectue actuellement.

    Et pour votre gouverne, l'ordre par défaut est celui de l'insertion. Et c'est pourquoi il est vivement conseillé de faire en sorte que le fichier (ou tout autre chose) soit triés selon la clef primaire avant d'effectuer le chargement dans la table.

    Citation Envoyé par fsmrel
    J’ai aussi rappelé que l’index intervient dans la soute, au niveau de la tuyauterie et n’a donc rien à voir avec la clé primaire, ça n’est qu’un fichier dont les plombiers ont eu l’idée de se servir pour héberger les valeurs prises par les attributs d’une table, notamment ceux qui composent une clé primaire et, physiquement, en garantir l’unicité.
    Le rôle de la clef primaire ne se cantonne pas uniquement à obtenir d'une part l'unicité de la valeur introduite et d'autre part de ne pas avoir de valeur 'NULL'. Ça, c'est la définition mathématique ou théorique.
    Une base de données doit obligatoirement reposer sur un support physique, au cas où cela vous aurait totalement échappé.
    Les choix qui sont faits sont des contraintes que la théorie ignore totalement. Mais elles ont leur raison d'être, même si cela vous dérange.
    Et une de ces raison est la performance. Tout l'intérêt d'un DBA est justement de savoir maintenir cette performance à une valeur presque optimale.

    Le rôle de la 'primary key' est de faire le lien entre la ligne insérée et la valeur de la clef. C'est-à-dire d'indiquer son emplacement sur le disque dur.
    Et comme cette clef primaire est aussi un indexe, l'indexe est trié selon l'ordre de la clef.
    Donc il ne faut pas mélanger l'ordre des valeurs de la clef dite primaire, et l'ordre de l'insertion des lignes, qui se fait selon la 'rowid'.
    De plus, s'il n'y avait pas de 'Primary key', je ne sais pas comment on pourrait retrouver la ligne, juste à partir de sa clef.

    Ensuite, chaque indexe fait toujours référence à la 'Primary Key' pour savoir où se trouve la ligne dont la valeur qui est indexée, y fait référence.
    ET oui, ne pensez pas que la tuyauterie soit moins importante que l'aspect théorique du sql dont vous semblez en faire l'éloge.
    Sans cette tuyauterie, les performances seraient désastreuses !

    Citation Envoyé par escartefigue
    C'est gentil de me remercier, mais relisez tous mes posts ci-dessus : je n'ai jamais écrit une énormité pareille !
    (j'ai moi même relu mes posts car j'ai failli faire un arrêt cardiaque )
    C'est tout le contraire : mettre un order by c'est pour trier, rien d'autre
    Voilà une énormité auquel je ne m'attendais pas ! Franchement, avez-vous un tant soit peu de bon sens, pour écrire une telle absurdité ?

    Si je n'ai pas d'indexe et que je demande par la clause 'order by' un résultat qui n'est pas celui de la clef primaire alors OUI, il y a aura un tri.
    Voir l'exemple ci-après :
    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
    24
    25
    26
    27
    28
    29
    30
    --------------
    describe test
    --------------
     
    +-------+------------------+------+-----+---------+-------+
    | Field | Type             | Null | Key | Default | Extra |
    +-------+------------------+------+-----+---------+-------+
    | col1  | int(10) unsigned | NO   | PRI | NULL    |       |
    | col2  | int(10) unsigned | NO   |     | NULL    |       |
    +-------+------------------+------+-----+---------+-------+
    --------------
    explain select * from test order by col2
    --------------
     
    +----+-------------+-------+------+---------------+------+---------+------+------+----------------+
    | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |
    +----+-------------+-------+------+---------------+------+---------+------+------+----------------+
    |  1 | SIMPLE      | test  | ALL  | NULL          | NULL | NULL    | NULL |    3 | Using filesort |
    +----+-------------+-------+------+---------------+------+---------+------+------+----------------+
    --------------
    select * from test order by col2
    --------------
     
    +------+------+
    | col1 | col2 |
    +------+------+
    |    2 |    1 |
    |    3 |    2 |
    |    1 |    3 |
    +------+------+
    Et comment je sais qu'il y a un tri ? Tout simplement en regardant la colonne 'extra' du explain. Il est indiqué 'using filesort'.

    Or l'exemple que j'avais donné était celui où j'avait un indexe sur la colonne 'col2' alors que je désire obtenir l'ordre selon la 'primary key'.
    Au cas où vous auriez oublié, c'est le problème que je rencontre et l'origine de mon sujet.

    L'exemple que je donne ci-après est celui où je demande à ce que mon 'select *' soit trié selon l'ordre de la colonne 'col2'.
    Or ici, j'ai un indexe sur cette colonne. En faisant 'select * from test order by col2', mon résultat sera bien ordonné, mais il n'y aura pas de tri !
    Ci-après l'exemple qui démontre mon affirmation :
    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
    24
    25
    26
    27
    28
    29
    30
    --------------
    describe test
    --------------
     
    +-------+------------------+------+-----+---------+-------+
    | Field | Type             | Null | Key | Default | Extra |
    +-------+------------------+------+-----+---------+-------+
    | col1  | int(10) unsigned | NO   | PRI | NULL    |       |
    | col2  | int(10) unsigned | NO   | UNI | NULL    |       |
    +-------+------------------+------+-----+---------+-------+
    --------------
    explain select * from test order by col2
    --------------
     
    +----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+
    | id | select_type | table | type  | possible_keys | key      | key_len | ref  | rows | Extra       |
    +----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+
    |  1 | SIMPLE      | test  | index | NULL          | jdx_col2 | 4       | NULL |    3 | Using index |
    +----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+
    --------------
    select * from test order by col2
    --------------
     
    +------+------+
    | col1 | col2 |
    +------+------+
    |    2 |    1 |
    |    3 |    2 |
    |    1 |    3 |
    +------+------+
    Et comment je sais qu'il n'y a pas eu de tri ? En regardant la colonne 'extra' de l'explain. Il est indiqué 'using index'.
    Ce qui signifie qu'il n'y a pas de tri mais que le 'full scan' de la table sera lu dans l'ordre de l'indexe 'idx_col2'.

    Alors je vais vous apprendre quelque chose, un 'order by' peut aussi forcer l'usage d'un indexe quand celui-ci existe !

    Citation Envoyé par sqlpro
    ENFIN !!! Hourra !!! vous commencez à percevoir les choses... Il serait temps !
    Mon interrogation était une forme d'ironie ! J'ai répondu à cette question ci-dessus dans ce message.

    Bon. Je termine ce sujet où je n'ai pas eu les réponses que j'attendais.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  20. #40
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Votre dernier post est un tissus d'énormités qui me sidère et laisse voir l'état d’inculture dans lequel vous vous trouvez !
    À peu près tout ce que vous affirmez est faux.
    Devant tant de bêtise je renonce à vous contredire, ne serait-ce que parce que de toutes façons vous n'entendrez pas des choses que l'on vous a déjà dites et que je ne perdrais pas encore mon temps avec vous, il y a des gens plus intelligents et plus ouverts...
    Mais si je fais ce post, c'est pour indiquer aux lecteurs qui risquent hélas vous lire que ce tissus d’âneries constitue la plus belle collection de choses à ne pas faire !
    Visiblement vous vous complaisez dans votre ignorance et refusez les éclaircissements de tout ceux qui ont participer à vous aider...

    C'est navrant et calamiteux !
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 3 PremièrePremière 123 DernièreDernière

Discussions similaires

  1. [MySQL] Problème de tri
    Par pounie dans le forum PHP & Base de données
    Réponses: 6
    Dernier message: 22/10/2005, 14h09
  2. Problème de tri avec analyse croisée
    Par drthodt dans le forum Access
    Réponses: 2
    Dernier message: 18/10/2005, 17h23
  3. [TToolBar] Problème de tri
    Par titiyo dans le forum Composants VCL
    Réponses: 6
    Dernier message: 01/09/2004, 10h21
  4. [Collections] Problème de tri
    Par feti2004 dans le forum Collection et Stream
    Réponses: 16
    Dernier message: 03/08/2004, 17h45
  5. problème de tri et optimisatiopn
    Par psyco2604 dans le forum XSL/XSLT/XPATH
    Réponses: 9
    Dernier message: 13/05/2004, 11h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo