Considérez ce qui suit:
Table EventTypes comporte 163 lignes. P>
Événements comporte 43 000 lignes. P>
mysql> EXPLAIN(SELECT events.eventTypeID, eventTypes.eventTypeName FROM events LEFT JOIN eventTypes ON events.eventTypeID = eventTypes.eventTypeID); +----+-------------+------------+--------+---------------+-------------+---------+-------------------------------+-------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+--------+---------------+-------------+---------+-------------------------------+-------+-------------+ | 1 | SIMPLE | events | index | NULL | eventTypeID | 4 | NULL | 37748 | Using index | | 1 | SIMPLE | eventTypes | eq_ref | PRIMARY | PRIMARY | 4 | casefriend.events.eventTypeID | 1 | | +----+-------------+------------+--------+---------------+-------------+---------+-------------------------------+-------+-------------+
3 Réponses :
J'ai essayé ceci à sqlfiddle: http://sqlfiddle.com/#!2/c9908b/ 1 i obtenir 20 rangées de retour comme prévu p> p>
J'ai chargé votre code dans ma base de données et je l'ai essayé et ça marche pour moi sur mon système également. Maintenant, pour déterminer ce qui est "spécial" avec ma situation ...
Quelle est la sortie sur votre système? Si seulement 5 lignes, dont 5 rangées?
J'ai fait de mon mieux pour copier ma structure et certaines données sur SQLFIDDLE et restez à l'intérieur de la limite de 8 000 caractères. J'ai réussi à faire un test réussi et il fonctionne correctement sur SQLfiddle. SQLFIDDLE.com/#!2/6C410/2 Donc, quelque chose d'étrange sur mes systèmes . Ensuite, j'essaie le jeu de données complet sur un 3ème serveur, je suppose.
Quelle version de mysql? Linux ou Windows? Pouvez-vous supprimer et réinstaller MySQL?
Je l'ai essayé avec des versions MySQL 5.5.29 et 5.1.61. Un sur un mac en cours d'exécution de lion de montagne avec MAMP (système de développement). L'autre est sur un serveur Centos6.
Merci pour le test avec 5 rangées. Cela a causé phpmyadmin à montrer son bogue. La barre de résultats verte a dit 5 mais j'avais une série de 30 premiers résultats à l'écran. Tout null. Si vous avez manqué la mise à jour, le client MySQL produit les résultats corrects.
La seule chose à laquelle je puisse penser, existe-t-il des espaces sur votre colonne d'identité. Parfois, cela fait une différence ..
SELECT events.eventTypeID, eventTypes.eventTypeName FROM events LEFT JOIN eventTypes ON events.eventTypeID = eventTypes.eventTypeID WHERE events.eventID >= 0 Beacuase if you mention (events.eventID >= 0) it means get all those rows they have this condition true and events table has 43000 rows and condition true for all rows and you using LEFT JOIN so you get 43000 rows
I would expect the lack of a WHERE clause would give me everything. Am I thinking about this wrong? Yes , you are right your first query is correct and it should return what you are expecting. You are using LEFT OUTER JOIN , which means all records from left table and matching records from right table.This is issue is not related to MYSQL version as my knowledge.My suggestion is ,please check the relation (foreign key and primary key) on which you are joining both table.
Qu'est-ce que
où 1 = 1 code> donne? :)Quelque chose ne va pas avec vos requêtes. Vous ne pouvez pas ajouter de
où code> clause et obtenez plus de lignes.@Hobbs où 1 = 1 fonctionne aussi.
@Gordonlinoff Linoff Je suis d'accord mais vous regardez les requêtes exactes. Je promets ce qui se passe est vrai.
@Timduncklee Eh bien, je n'ai aucune idée, mais au moins c'est un autre point de données.
@hobbs je viens d'essayer d'où 1. Curieusement cela ne fonctionne pas (c'est-à-dire renvoyer seulement 163 rangées). J'ai aussi essayé de changer le moteur de Innodb à Myisam. Aucune différence.
Votre seconde i> La requête est la seule produisant des résultats corrects - c'est un
rejoindre code> que vous utilisez après tout. Je suppose que quelque chose sur les tableaux / indices provoque l'optimisation d'agir drôle (c'est-à-dire en considérant comme une jointure intérieure code> code> à la place). Votreoù code> Clause fait ainsi que Optimizer se rendit compte "mec, il voulait vraiment dire cela". Donc, ce n'est pas que leoù la clause code> vous donne plus de résultats, c'est que quelque chose à propos de la situation vous donne moins de résultats i> pour une raison quelconque.@ Clockwork-Muse Inner Rejoignez toujours seulement me donne 163 enregistrements. Je soupçonne que vous êtes correct sur l'optimiseur. Je vais essayer cette structure et cette donnée sur un 3ème serveur.
Obtenez la sortie à partir d'une explication (
expliquer ... code>) sur les deux requêtes. Je n'ai pas rencontré ce problème sur MySQL avant; Mais j'ai eu ce genre de problème sur Oracle, où une balayage de table complète rencontrait une corruption (une marque de hautes eaux fausses), mais ajoutant un indice, pour obtenir l'optimiseur d'utiliser l'index, je pourrais obtenir toutes les lignes. Aucune erreur n'est retournée. Ce qui est étrange de votre cas, c'est que le nombre de lignes renvoyées correspond au nombre de lignes dans l'une des tables.Pouvez-vous répéter le test, mais utiliser un nom de table autre que
événements code>? (Je me demandais simplement s'il y a du code dans l'optimiseur pour une manipulation spéciale de la table Information_schema.events; chose d'autre d'autre sur les tables (blob, texte, etc., clés de caractères, classement incompatible ... envisagez de fournir la sortie à partir d'unAfficher la table Create Code>)@ Spencer7593 Je viens d'ajouter l'explication à ma question. Voulez-vous dire changer le nom de la table et l'essayer à nouveau? Je n'ai pas une autre table existante avec les mêmes données. Si vous vous demandez si le problème est un problème avec d'autres jointures gauche, non. Je fais beaucoup de mysql et je n'ai jamais vécu cela. J'ai travaillé à cela pendant de nombreuses heures avec beaucoup de frustration parce que je savais que mes requêtes étaient correctes. Je les fais dans mon sommeil ... lol
Cela aurait beaucoup contribué si vous aviez mentionné PHPMYADMIN pour commencer.
@JimGarrison Vous êtes correct. J'aurais dû penser à cela. :(
La première requête doit revenir essentiellement tous les enregistrements de la table des événements et des correspondances dans eSuPersypes..Ce doit être 63000. Le> = 0 condition de la deuxième requête implique que vous renvoyez tous les enregistrements de la table d'événements qui correspondent aux enregistrements de la table EventType ... Devrait RFETURN 163
Vérifiez la version stable sur phpmyadmin. J'utilise assez souvent Pma (même si je préfère CLI) et ça marche bien