working on what Code-Monk wrote, consider the following:
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 Stored Procedure
call uspK(); -- test it, no warnings on edge conditions
What not to do
One would not find much luck with the following. If you think so, run it a few times;
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
because create temporary table if not exists temp
is flakey
General Comments
One should not embark into writing stored procs until somewhat fluent on the simple topic of DELIMITERS. Wrote about them in a section here called Delimiters. Just hoping to head you off from unnecessary wasted time on such a simple thing, than can waste a lot of debugging time.
Also, here in your question, as well as in that reference, keep in mind that the creation of tables is DDL that can have a large percentage of the overall profiling (performance). It slows down a proc versus using a pre-existing table. One might think the call is instantaneous, but it is not. As such, for performance, using a pre-existing table with ones results put into their own segmented rowId is much faster than enduring DDL overhead.