First, from looking at your existing indexes and comparing them to your example query, you are missing an index on just accountid
. The way MySQL handles indexes is left-most, meaning you can have a composite index like this:
KEY `contactaccounts` (`contactid`,`accountid`,`journalcode`) USING BTREE,
and run a query that looks for contactid
and the contactaccounts
index would be a potential index*. However doing a query on accountid
will not utilize the index, because accountid
is not the left-most column.
If you never search for contactid
without an accountid
, I would create the index like this:
DROP INDEX `contactaccounts` ON `tbl_sessions_2012`;
CREATE INDEX `accountscontact` ON `tbl_sessions_2012` (`accountid`,`contactid`,`journalcode`);
Now, analyzing your other indexes, the first of each set is redundant using the left-most rule, and can be dropped in favor of the second:
KEY `contactaccounts` (`contactid`,`accountid`,`journalcode`) USING BTREE
KEY `contactaccountloginmonths` (`contactid`,`accountid`,`journalcode`,`logintypeid`,`actionTime`) USING BTREE
KEY `contactaccountcollections` (`contactid`,`accountcollectionid`,`journalcode`) USING BTREE
KEY `contactaccountcollectionloginmonths` (`contactid`,`accountcollectionid`,`journalcode`,`logintypeid`,`actionTime`) USING BTREE
KEY `organisationaccounts` (`organisationid`,`accountid`) USING BTREE
KEY `organisationaccountloginmonths` (`organisationid`,`accountid`,`journalcode`,`logintypeid`,`actionTime`) USING BTREE
KEY `organisationaccountcollection` (`organisationid`,`accountcollectionid`,`journalcode`) USING BTREE
KEY `organisationaccountcollectionsloginmonths` (`organisationid`,`accountcollectionid`,`journalcode`,`logintypeid`,`actionTime`) USING BTREE
By having the duplicates you are using up a lot of space on indexes.
* I say potential because there is still the possibility that your index will not be used due to the amount of rows MySQL has to scan through. As your account_id IN ()
statement grows, MySQL will determine that it's faster just to do a full table scan regardless of the index.
I find this troubling for two reasons
REASON #1
This could be a bug that never got squashed out of MySQL 5.5.17
REASON #2
You are trying to acquire a metadata lock on an InnoDB table in an RDS environment? Ouch !!!
Possible Workaround
Instead of trusting the metadata locking in RDS, ask the information_schema if the table exists already. Suppose the table is mydb.backupfiles
. Run this query:
SELECT COUNT(1) FROM information_schema.tables
WHERE table_schema='mydb' AND table_name='backupfiles';
If the answer comes back 0, run CREATE TABLE backupfiles ...
. Otherwise, don't run it.
Possible Solution
Upgrade to the Latest MySQL (5.6.12) or the Latest MySQL5.5 (5.5.31). Hopefully, this issue was solved in a more recent version
Give it a Try !!!
UPDATE 2013-07-11 15:16 EDT
Here is a rewrite of your bash code to check if the table already exists
echo "CREATE DATABASE IF NOT EXISTS $DATABASE;" > /tmp/runthis.sql
echo "use $DATABASE;" >> /tmp/runthis.sql
SQLSTMT="SELECT COUNT(1) FROM information_schema.tables"
SQLSTMT="${SQLSTMT} WHERE table_schema='${DATABASE}' AND table_name='backupfiles';"
TABLE_EXISTS=`mysql -h portal-rds -u $user --password=$mysqlpw -ANe"${SQLSTMT}"`
if [[ ${TABLE_EXISTS} -eq 0 ]]; then
SQLSTMT="CREATE TABLE backupfiles (fileName VARCHAR(20),"
SQLSTMT="${SQLSTMT} archiveId VARCHAR(500), checkSum VARCHAR(100),"
SQLSTMT="${SQLSTMT} glacierVault VARCHAR(100), timeStamp date);"
echo "${SQLSTMT}" >> /tmp/runthis.sql
fi
SQLSTMT="INSERT INTO backupfiles VALUES ('$archive_file_name',"
SQLSTMT="${SQLSTMT} '$archiveID', '$CURRENTVAULT', '$checkSum', CURDATE());"
echo "${SQLSTMT}" >> /tmp/runthis.sql
echo "COMMIT;" >> /tmp/runthis.sql
mysql -h portal-rds -u $user --password=$mysqlpw < /tmp/runthis.sql
Best Answer
The mysql client has the
init-command
option, which does what you want, I think.From the manual: