Je suis actuellement occupé à implémenter un type de filtre pour lequel je dois générer un clausse INNER JOIN pour chaque "tag" sur lequel filtrer.
Le problème est qu'après tout un tas de SQL, j'ai une table qui contient toutes les informations dont j'ai besoin pour faire ma sélection, mais j'en ai encore besoin pour chaque INNER JOIN généré
Cela ressemble essentiellement à:
SELECT
*
FROM search
INNER JOIN search f1 ON f1.baseID = search.baseID AND f1.condition = condition1
INNER JOIN search f2 ON f2.baseID = search.baseID AND f2.condition = condition2
...
INNER JOIN search fN ON fN.baseID = search.baseID AND fN.condition = conditionN
Cela fonctionne mais je préférerais de loin que la table de «recherche» soit temporaire (elle peut être plusieurs ordres de grandeur plus petite si ce n'est pas une table normale) mais cela me donne une erreur très ennuyeuse: Can't reopen table
Certaines recherches m'amènent à ce rapport de bogue, mais les gens de MySQL ne semblent pas se soucier du fait qu'une telle fonctionnalité de base (en utilisant une table plus d'une fois) ne fonctionne pas avec des tables temporaires. Je rencontre beaucoup de problèmes d'évolutivité avec ce problème.
Existe-t-il une solution de contournement viable qui ne m'oblige pas à gérer potentiellement beaucoup de tables temporaires mais très réelles ou à me faire maintenir une énorme table avec toutes les données?
Cordialement, Kris
[Additionnel]
La réponse GROUP_CONCAT ne fonctionne pas dans ma situation car mes conditions sont plusieurs colonnes dans un ordre spécifique, cela ferait des OU à partir de ce dont j'ai besoin pour être des ET. Cependant, cela m'a aidé à résoudre un problème antérieur, donc maintenant la table, temporaire ou non, n'est plus nécessaire. Nous pensions juste trop générique pour notre problème. L'ensemble de l'application des filtres est désormais ramené d'environ une minute à bien moins d'un quart de seconde.
la source
Réponses:
Si le passage à MariaDB (un fork de MySQL) est faisable - ce désagrément y est corrigé à partir de la version 10.2.1: https://jira.mariadb.org/browse/MDEV-5535 .
la source
Une solution simple consiste à dupliquer la table temporaire. Fonctionne bien si la table est relativement petite, ce qui est souvent le cas des tables temporaires.
la source
À droite, la documentation MySQL dit: "Vous ne pouvez pas faire référence à une
TEMPORARY
table plus d'une fois dans la même requête."Voici une requête alternative qui devrait trouver les mêmes lignes, bien que toutes les conditions des lignes correspondantes ne soient pas dans des colonnes séparées, elles seront dans une liste séparée par des virgules.
la source
J'ai contourné cela en créant une table "temporaire" permanente et en suffixant le SPID (désolé, je suis du pays SQL Server) au nom de la table, pour créer un nom de table unique. Créez ensuite des instructions SQL dynamiques pour créer les requêtes. Si quelque chose de mauvais se produit, la table sera supprimée et recréée.
J'espère une meilleure option. Allez, MySQL Devs. Le 'bug' / 'feature request' est ouvert depuis 2008! On dirait que tous les «bugs» rencontrés sont dans le même bateau.
la source
Personnellement, je n'en ferais qu'une table permanente. Vous voudrez peut-être créer une base de données distincte pour ces tables (elles auront probablement besoin de noms uniques car beaucoup de ces requêtes peuvent être effectuées à la fois), également pour permettre la définition judicieuse des autorisations (vous pouvez définir des autorisations sur les bases de données; vous pouvez ' t définir les autorisations sur les caractères génériques de table).
Ensuite, vous auriez également besoin d'un travail de nettoyage pour supprimer les anciens de temps en temps (MySQL se souvient facilement de l'heure à laquelle une table a été créée, vous pouvez donc simplement l'utiliser pour déterminer lorsqu'un nettoyage était nécessaire)
la source
J'ai pu changer la requête en table permanente et cela l'a corrigé pour moi. (modification des paramètres VLDB dans MicroStrategy, type de table temporaire).
la source
Vous pouvez le contourner en créant une table permanente, que vous supprimerez par la suite, ou en créant simplement 2 tables temporaires séparées avec les mêmes données
la source
Voici la documentation MYSQL sur ce problème. J'utilise des tables temporaires en double comme certaines des réponses ci-dessus, cependant, vous pouvez avoir une situation où un CTE est approprié!
https://dev.mysql.com/doc/refman/8.0/en/temporary-table-problems.html
la source