arbetar på vad Code-Monk skrev, tänk på följande:
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
Testa lagrad procedur
call uspK(); -- test it, no warnings on edge conditions
Vad man inte ska göra
Man skulle inte hitta mycket lycka med följande. Om du tror det, kör det några gånger;
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
eftersom create temporary table if not exists temp
är fläckig
Allmänna kommentarer
Man bör inte ge sig i kast med att skriva lagrade processer förrän man är något flytande på det enkla ämnet AVGRÄNSNINGAR. Skrev om dem i ett avsnitt här kallas Avgränsare . Bara att hoppas på att få bort dig från onödig slöseri med en så enkel sak, än kan slösa bort mycket tid för felsökning.
Tänk också på att skapandet av tabeller är DDL här i din fråga, såväl som i den referensen. som kan har en stor andel av den övergripande profileringen (prestanda). Det saktar ner en proc jämfört med att använda en redan existerande tabell. Man kan tro att samtalet är omedelbart, men det är det inte. Som sådan, för prestanda, är det mycket snabbare att använda en redan existerande tabell med ett resultat i sin egen segmenterade rad-ID än att uthärda DDL-overhead.