MySQL Sum Very Slow On Small Number of Rows - mysql

Question

I can't figure out why MySQL is so slow summing less than 400 rows. Both u and t have indexes and return the rows quickly.
SELECT sum(t) FROM `s_table`
WHERE `u` LIKE 'dogs%'
AND `t`> 10000
Query took 3.5299
If I remove the sum part of the query.
SELECT t FROM `s_table`
WHERE `u` LIKE 'dogs%'
AND `t`> 10000
Query took 0.0090 seconds returns 397 rows.
So to sum 397 rows takes over 3 seconds!
Then I tried.
SELECT SUM(t)
FROM ( SELECT t
FROM s_table
WHERE `u` LIKE 'dogs%'
AND `t`> 10000
) AS total;
Query took 3.5767 seconds, so basically the same as the first query.
I'm going insane here. Why is it taking MySQL over 3 seconds to sum only 398 numbers?
Here is the explain:
CREATE TABLE `s_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`s` varchar(100) NOT NULL,
`v` int(12) NOT NULL,
`c` float NOT NULL,
`r` int(3) NOT NULL,
`u` varchar(350) NOT NULL,
`w` int(1) NOT NULL,
`t` int(12) NOT NULL,
`date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_v` (`v`),
KEY `idx_c` (`c`),
KEY `idx_r` (`r`),
KEY `idx_u` (`u`),
KEY `idx_t` (`t`),
KEY `idx_date` (`date`),
KEY `s` (`s`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED

Answer 1

Change these
KEY `idx_u` (`u`),
KEY `idx_t` (`t`),
to
KEY `u_t` (`u`, `t`),
KEY `t_u` (`t`, `u`),
I said "change", not "add". I have seen cases where "adding" a composite index did not change the Optimizer's choice of index; I think this is a bug. Note that these 2-column indexes are "covering", which, by itself, gives a performance boost.
Don't use ROW_FORMAT=COMPRESSED, it may be expending a lot of effort in uncompressing to run the query.
The UI you are using seems to stop at 25 rows -- this could explain the extra speed.
What do you get from these? (They may help in analyzing things.)
How many rows "need" to be looked at by each single-column index:
SELECT SUM(U LIKE 'dogs%'), SUM(t > 10000) FROM s_table;
More details than a plain EXPLAIN:
EXPLAIN FORMAT=JSON SELECT ... -- your query
This will definitively say whether 397 versus 272580 rows were fetched:
FLUSH STATUS;
SELECT ...; -- your query
SHOW SESSION STATUS LIKE 'Handler%';