Insérer une table temporaire MySQL

en travaillant sur ce que Code-Monk a écrit, considérez ce qui suit :

drop procedure if exists uspK;
DELIMITER $$
create procedure uspK ()
BEGIN
    drop temporary table if exists temp; -- could be some other random structure residue

    create temporary table temp
    SELECT aID, bID
    FROM tags
    WHERE placeID = "abc" AND tagID = "def";

    -- use the temp table somehow
    -- ...
    -- ...
    -- ...

    drop temporary table temp; -- otherwise it survives the stored proc call
END
$$ -- signify end of block
DELIMITER ; -- reset to default delimiter

Tester la procédure stockée

call uspK(); -- test it, no warnings on edge conditions

Ce qu'il ne faut pas faire

On ne ferait pas trouver beaucoup de chance avec ce qui suit. Si vous pensez que oui, lancez-le plusieurs fois ;

drop procedure if exists uspK;
DELIMITER $$
create procedure uspK ()
BEGIN
    -- drop temporary table if exists temp;

    create temporary table if not exists temp
    SELECT aID, bID
    FROM tags
    WHERE placeID = "abc" AND tagID = "def";

    -- use the temp table somehow
    -- ...
    -- ...
    -- ...

    -- drop temporary table temp; -- otherwise it survives the stored proc call
END
$$ -- signify end of block
DELIMITER ; -- reset to default delimiter

parce que create temporary table if not exists temp est floconneux

Commentaires généraux

Il ne faut pas se lancer dans l'écriture de procs stockés tant qu'on n'est pas assez à l'aise sur le sujet simple des DELIMITERS. Écrit à leur sujet dans une section ici appelés Délimiteurs . En espérant simplement vous éviter de perdre du temps inutilement sur une chose aussi simple, cela peut vous faire perdre beaucoup de temps de débogage.

De plus, ici dans votre question, ainsi que dans cette référence, gardez à l'esprit que la création de tables est DDL qui peut ont un grand pourcentage du profilage global (performance). Il ralentit un proc par rapport à l'utilisation d'une table préexistante. On pourrait penser que l'appel est instantané, mais ce n'est pas le cas. En tant que tel, pour les performances, l'utilisation d'une table préexistante avec ses résultats placés dans son propre rowId segmenté est beaucoup plus rapide que la surcharge DDL durable.