Speed Up Concurrent Lightweight SQL Queries - mysql

Question

I have an application that needs to make many concurrent lightweight SQL queries. For example - the unit query is like "For this store, give me a list of sales by category today." Alone this query is very cheap - it runs in a few tens of milliseconds at most.
I need to perform this query at a store level - "For every transaction of this store group (roughly up to 30), give a list of sales by category today." This is obviously implementable as a join on the set of stores in the group - but this is too slow. It slows down proportionally to the number of transactions made (in reality, in proportion to the total number of items bought).
Instead I've implemented it as many concurrent store-level queries (I've varied the batch size to no real avail) and then I merge the results in the application layer. This works reasonably well, especially when combined with PreparedStatements. Unfortunately this is not fast enough. This takes query times from 5-15 seconds to 0.5-1.5 seconds for the majority of the time, but occasionally it will take 3 seconds, which is outside of the acceptable performance range (less than 2 seconds).
The information is not cacheable as it's unlikely that the same query will be executed within an acceptable caching time frame. Note that queries for the recent past (two weeks or so) perform very quickly - as the DB writes keep that section of the data fresh in the DB/OS cache. It's random reads that are killer.
Do any of you DB wizards have any tips to speed up this query process? I'm very new to SQL and nobody in my office has tried anything like this before. I have benchmarked and timed them very thoroughly, and I am pretty sure it's this spin-off of up to 100 queries (30 * 3 metrics + some simpler queries) simultaneously that is costing me the time. A list of query times looks like [10, 15, 30, 55, 89, 100, 300, ..., 1599], all timed only around the execute() call. For reference I'm using Java as the application language with C3P0 and 500-1000 open DB connections and Amazon Aurora as the DB. I've even tried load-balancing the 100 queries across two read-replicas, but this seems to only nominally improve performance, much to my dismay. I got a small performance boost from TRANSACTION_READ_UNCOMMITTED and SCROLL_INSENSITIVE + READ_ONLY, I think.
Edit: Some table structures and queries (Pardon the name transaction - I don't actually use this name but have changed it for business reasons.)
CREATE TABLE IF NOT EXISTS item (
item_id BIGINT UNSIGNED AUTO_INCREMENT,
item_name VARCHAR(120),
unit_price DECIMAL (10,2),
PRIMARY KEY (item_id)
) ENGINE=INNODB;
CREATE TABLE IF NOT EXISTS transaction_item_list (
ticket_transaction_id BIGINT UNSIGNED AUTO_INCREMENT,
transaction_id BIGINT UNSIGNED,
item_id BIGINT UNSIGNED,
item_quantity DECIMAL(10,2),
item_sales DECIMAL(10,2),
FOREIGN KEY (item_id)
REFERENCES item (item_id),
FOREIGN KEY (transaction_id)
REFERENCES transaction (transaction_id),
PRIMARY KEY (transaction_item_id)
) ENGINE=INNODB;
CREATE INDEX transaction_id_idx
ON transaction_item_list (transaction_id);
CREATE INDEX item_id_idx
ON transaction_item_list (item_id);
CREATE TABLE IF NOT EXISTS transaction (
transaction_id BIGINT UNSIGNED AUTO_INCREMENT,
native_transaction_id VARCHAR(36) NOT NULL,
store_id BIGINT UNSIGNED NOT NULL,
server_time DATETIME NOT NULL,
business_date DATE NOT NULL,
FOREIGN KEY (store_id)
REFERENCES store (store_id),
PRIMARY KEY (transaction_id)
) ENGINE=INNODB;
# used for insertion
CREATE UNIQUE INDEX store_date_native_transaction_id_idx
ON ticket (store_id, business_date, native_transaction_id);
# used for querying
CREATE UNIQUE INDEX store_date_transaction_id_idx
ON ticket (store_id, business_date, transaction_id);
CREATE INDEX store_id_idx
ON transaction (store_id);
CREATE INDEX date_idx
ON transaction (business_date);
CREATE INDEX server_time_idx
ON transaction (server_time);
SELECT sum(transaction_item_list.item_quantity * item.unit_price) FROM transaction_item_list
JOIN item USING (item_id)
JOIN transaction USING (transaction_id)
WHERE (transaction.store_id, transaction.transaction_date) IN ((?, ?))
GROUP BY category;
The transaction_item_list table has over 700 million rows for one year's worth of data.

Answer 1

Do not use this constructWHERE (store_id, transaction_date) IN ((?, ?)); it optimizes poorly. Instead, use
WHERE store_id = ?
AND transaction_date = ?
Please qualify each column mentioned in a JOIN with the table name (or alias); it is tedious for the reader (us) to figure out which comes from where.
Indexes needed:
transaction: INDEX(store_id, transaction_date) -- in that order
transaction_item_list: INDEX(transaction_id) -- if not already there
transaction_item_list smells like a many:many mapping (plus an extra column). If it is, see my 7 tips on many:many .