SELECT * FROM mm_tfs
WHERE product_description LIKE '%football%'
AND schoolid = '8' AND category_id ='21'
3 Réponses :
Essayez de mettre () autour de toute la condition
SELECT * FROM mm_tfs WHERE ( (product_slug LIKE '%football%' AND schoolid = '8' AND category_id ='21') OR (product_description LIKE '%football%' AND schoolid = '8' AND category_id ='21') ) LIMIT 4
Nope, ne change pas de résultats à partir de 0
Aurait-il besoin de ces supports s'il n'avait pas Limite 4 Déclaration?
@Bob Cavezza - Éliminer les petits morceaux pour voir le problème. Par exemple, éloignez-vous des 2 et de la partie de la part de la ou de la partie et de l'avoir juste ou produit_description comme '% Football%' ... puis voir si des lignes reviennent. Je ferais un usage de (et) d'autres. Ceux-ci et et ours pourraient buendre cela pour y ...
J'ai fait - cette deuxième déclaration renvoie des valeurs attendues comme la première déclaration a fait - ce qui rend cela encore plus perplexe
Vous répétez certaines des conditions qui ne sont pas nécessaires. Essayez cela à la place:
select * from mm_tfs2 where (slug like '%football%' and schoolid = 8 and categoryid = 21) or (description like '%football%' and schoolid = 8 and categoryid = 21) limit 4; +----------+------------+-------------+----------+ | schoolid | categoryid | description | slug | +----------+------------+-------------+----------+ | 8 | 21 | | football | | 8 | 21 | | football | | 8 | 21 | | football | | 8 | 21 | | football | +----------+------------+-------------+----------+ 4 rows in set (0.00 sec)
Bien que cela soit vrai, explique-t-il pourquoi la requête ne fonctionne pas?
@cyberwiki: Permet de voir votre réponse, pantalon Smarty: P
@Voodoochild - Nous essayons de comprendre pourquoi ou ne fonctionne pas. Cette réponse ne résout pas que
@cyberkiwi: Oui, je suis intéressé à savoir pourquoi cela ne fonctionne pas aussi bien.
Oui, tu as raison ... ça n'explique pas pourquoi la requête de l'OP ne fonctionne pas. Hmmmm ...
@cyberkiwi, je ne suis pas capable de reproduire le problème sur mon propre serveur MySQL.
@Bob Cavezza, cela fonctionne bien sur mon serveur avec et sans la limite . Je me demande quelle est votre définition de table.
@Klaus Tout est configuré comme varchar utf8_generaleral_ci - est-ce ce que vous parlez de?
@Bob, après avoir modifié les identifiants d'INTS vers Varchar, je ne suis toujours pas capable de reproduire le problème :-(
Wow, allant certainement au-dessus et au-delà, mais j'ai bien peur que ce soit une cause perdue. J'apprécie vraiment l'aide. :-)
i pense em> vous pouvez le nettoyer un peu, vous obtenez seulement des lignes pour une école et une pièce d'identité de la catégorie, il n'ya donc aucune raison que vous devriez avoir à vérifier ces deux fois : SELECT *
FROM mm_tfs
WHERE schoolid = '8'
AND category_id ='21'
AND (product_slug LIKE '%football%'
OR product_description LIKE '%football%')
LIMIT 4;
Hmm, battu par Klaus. Besoin d'être plus rapide la prochaine fois. : P
Lol @galador, vous avez tout le temps du monde pour expliquer à WTH? Voir les commentaires en op). Je vais uppoter pour la clouer.
Semble être une erreur logique booléenne plutôt que spécifique à ou. Enveloppez toute la chose autour des accolades, c'est toute votre condition autour (et).
C'est très intéressant. Quelqu'un peut-il expliquer pourquoi il est faux au lieu de donner une approche alternative? +1
J'ai édité la question mais pouvez-vous confirmer à nouveau que les requêtes sont comme indiqué? Les requêtes sont-elles formatées par PHP ou allez-vous directement à partir de la console?
@Nishant - Je n'ai pas de mysql, mais pour moi, c'est probablement une erreur de logique booléenne. C'est pourquoi j'ai suggéré de nuire à la requête en supprimant certaines conditions, testant et seulement la lecture des pièces dépouillées étant donné que le problème disparaît.
@Jonh je ne pense pas. Je visualise de cette façon, le moteur MySQL va à une rangée et le comparateur contre le premier ou le bloc. Il manche et résultat renvoyé. De même que les deux conditions sont identiques, ce devrait travailler, à moins que l'OP ait commis une erreur dans la copie de la requête exacte de sa console.
Je ne peux pas reproduire le problème. Essayez de poster votre définition de table.
Je posterais ce bug sur mysql. Joignez votre DB si possible et incluez la version MySQL exacte
Est comme «% variable%» sensible à la casse?
@cyberkiwi je ne peux pas reproduire cela.
Une autre raison de ne pas utiliser MySQL. Désolé juste devait ...
@Bob Caveza: Nous aurions besoin de votre version MySQL, de la définition de la table et si possible certaines données de ce tableau pour voir si elle peut être reproduite.
@Jonh: Ouais ... Un autre exemple d'hypothèses basées sur des données incomplètes. Désolé, il suffit de.
Pouvez-vous faire une explication pour
toutes les questions ? Je soupçonne que MySQL fait quelque chose de drôle. Vous n'utilisez pas cela une sous-requête quelque part ailleurs êtes-vous?@MCHL - Je ne sais pas que je me souviens de MySQL ayant un bogue dans le nombre de jours dans un mois ....
@Jonh: Félicitations pour des souvenirs sucrés (je serais reconnaissant si vous avez fourni un numéro de bogue). Remarquez cependant que dans l'affaire, personne n'a été capable de reproduire le comportement jusqu'à présent.
Mysql - 5.0.77-LOG si cela aide
@MCHL - Merci pour les félicitations, cela m'a fait sourire :)
@BOB CAVEZZA: J'ai examiné Changelogs pour quelques versions suivantes à la suite de 5.0.77 et n'a rien vu d'indiquer qu'il y avait un bug comme celui-ci. Veuillez ajouter la sortie de
show créer créer une table mm_tfs à votre question (vous devriez être capable de le modifier)School_id et Catégorie_id sont-ils vraiment du texte, pas des entiers?
Wow! Cette question est devenu beaucoup plus longtemps depuis que je l'ai favorisé. (Cependant, tous mes favoris sont temporaires. J'ai décidé de voter la question cependant)
Non, je me suis trompé à propos de l'école_id (c'est entier), mais la catégorieID est Varchar - provient de l'API de programme d'affiliation en utilisant des lettres ainsi que des chiffres.