arbejder på, hvad Code-Monk skrev, overveje følgende:
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
Test lagret procedure
call uspK(); -- test it, no warnings on edge conditions
Hvad skal man ikke gøre
Man ville ikke finde meget held med følgende. Hvis du tror det, så kør det et par gange;
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
fordi create temporary table if not exists temp
er flakey
Generelle kommentarer
Man bør ikke gå i gang med at skrive lagrede procs, før man er lidt flydende om det simple emne afgrænser. Skrev om dem i et afsnit her kaldet Afgrænsere . Bare jeg håber på at komme væk fra unødvendig spildtid på sådan en simpel ting, så kan det spilde en masse fejlretningstid.
Husk også her i dit spørgsmål, såvel som i den reference, at oprettelsen af tabeller er DDL som kan har en stor procentdel af den samlede profilering (performance). Det sænker en proc i forhold til at bruge en allerede eksisterende tabel. Man kunne tro, at opkaldet er øjeblikkeligt, men det er det ikke. Som sådan, for ydeevne, er det meget hurtigere at bruge en allerede eksisterende tabel med resultater indsat i deres egen segmenterede række-id end at udholde DDL-overhead.