I'm going to skip past your questions and try to offer broader guidelines/advice instead.
The definitive/canonical guide to dynamic SQL, the situations where it is applicable and where it can be avoided, is Erland Sommarskog's Dynamic Search Conditions in T-SQL. Read it, re-read, run through Erland's examples, make sure you understand the reasoning behind the recommendations.
You're dealing with a fairly common scenario and the approach you've taken is not unusual. A couple of points worth highlighting:
- Using temporary tables is probably unnecessary. Is there a reason they were introduced?
- You have probably over-indexed the table. Read Kimberly Tripp's "just because you can, doesn't mean you should" article on the topic.
- Because you've over-indexed on individual columns, you're probably lacking good covering indexes. With so many aggregations and such a wide range of search conditions, these will be a challenge to get right.
Now the most important part of getting these kinds of searches right... apply the 80/20 rule.
The majority of calls to your procedure are likely to comprise a relatively small number of the possible variations of parameters. You cannot create optimal indexes for all combinations of 15 parameters, so identify the most common patterns, create static stored procedures for these and index for them appropriately. Deal with the remaining combinations with dynamic SQL, following Erland's best practices.
In these scenarios, you will often find the usage patterns closer to 95/5 than 80/20 so the additional work of creating static procedures is not as labour intensive as it seems at first glance.
Having taken a quick look at the Stored Procedure, I have three suggestions
SUGGESTION #1
The table norep_banner_zone_in
(lines 198-210) is MyISAM. Perhaps it should a MEMORY table.
DROP TABLE IF EXISTS norep_banner_zone_in;
CREATE TEMPORARY TABLE `norep_banner_zone_in` (
`channelid` INT ,
`zoneid` INT ,
`location` TINYINT(4) ,
`bannerid` INT ,
`CTR` DECIMAL(6,3) ,
`money` INT,
KEY `channelid` (`channelid`) ,
KEY `zoneid` (`zoneid`) ,
KEY `bannerid` (`bannerid`) ,
KEY `location` (`location`)
)ENGINE=MEMORY;
SUGGESTION #2
By default, table indexes for the MEMORY Storage Engine using HASH indexes. Try changing the CREATE TABLE
statements on all the MEMORY tables to use BTREEs. This may help with any ranged-based queries (such as lines 306,318,425) and INNER JOINs.
For example,
DROP TABLE IF EXISTS norep_banner_zone_in;
CREATE TEMPORARY TABLE `norep_banner_zone_in` (
`channelid` INT ,
`zoneid` INT ,
`location` TINYINT(4) ,
`bannerid` INT ,
`CTR` DECIMAL(6,3) ,
`money` INT,
KEY `channelid` (`channelid`) USING BTREE,
KEY `zoneid` (`zoneid`) USING BTREE,
KEY `bannerid` (`bannerid`) USING BTREE,
KEY `location` (`location`) USING BTREE
)ENGINE=MEMORY;
SUGGESTION #3
Instead of Dropping and Recreating the Table, why not Create if not exists and Truncate?
CREATE TEMPORARY TABLE IF NOT EXISTS `norep_banner_zone_in` (
`channelid` INT ,
`zoneid` INT ,
`location` TINYINT(4) ,
`bannerid` INT ,
`CTR` DECIMAL(6,3) ,
`money` INT,
KEY `channelid` (`channelid`) USING BTREE,
KEY `zoneid` (`zoneid`) USING BTREE,
KEY `bannerid` (`bannerid`) USING BTREE,
KEY `location` (`location`) USING BTREE
)ENGINE=MEMORY;
TRUNCATE TABLE norep_banner_zone_in;
Give it a Try !!!
Best Answer
You can do it in a single statement.