Mybatis group by query timeout

Question

i have met odd problem used mybatis3.1 +spring. this is my xml code

select (case when sum(hotplay_vv)>0 then sum(hotplay_vv) else 0 end) as provincevv , province_id as provinceid from hotplay_vv where dt>=#{startdt} and dt<=#{enddt} and brand_id=#{brandId} and hotplay_id=#{hotplayId} group by province_id ]]>
this is my test code:

 @Test
 public void testSearchValue() {

 List< Province >sumvv= (List<Province>) service.getSumGroupProvinces("2014-01-20", "2014-02-01", 1,1000);

  System.out.println("total-->"+sumvv.get(0).getProvinceVV()+" size-->"+sumvv.size());

  Assert.assertEquals(59346, sumvv.get(0).getProvinceVV());

 }

when i choose the end time '2014-02-01' i could get the value but changed to '2014-02-10',there isn't result return ,how can i solve this problem ....

Answer 1

Absent any other information about the table columns, indexes, cardinality, and so on,,, my immediate knee jerk reaction is that best performance for this query will be obtained when an appropirate covering index is available.

For example,

... ON hotplay_vv (hotplay_id, brand_id, province_id, dt, hotplay_vv)

Why those columns in that order? First, that's all the columns referenced in the query, so the query can be satisified from the index without an need to access the pages in the table. That's what's meant by a "covering" index.

The hotplay_id and brand_id columns are first, because there are equality predicates on those columns. With reasonable cardinality on those columns, we'd expect that to be relatively small subset of all rows in the table, so that should give us index range scan operation, which will zero in on the rows that we need, without a need to inspect a lot of rows that we don't need. The order of these columns in the index is probably not important for this particular query, so whichever order benefits other queries is probably the deciding factor, otherwise, we'd prefer to have the column with the highest cardinality.as the leading column.

The province_id column is next, because there's a GROUP BY operation on that. (The net effect is the same as a GROUP BY hotplay_id, brand_id, province_id, since we have only one value for the first two columns.

The dt column is next... it's not clear if MySQL has to look at all the dt values, or whether it can do a lower level range scan to optimize this or not.

And finally the hotplay_vv column is included so we can get the value from the index without having to visit the table pages.

We'd expect an EXPLAIN to show 'Using index' and avoding a filesort operation.

---

An index range scan on dt looks appealing for a small number of rows, an index .

... ON hotplay_vv (hotplay_id, brand_id, dt, province_id, hotplay_vv)

But if the number of rows accessed is significant, a "Using filesort" operation to perform the GROUP BY operation is less appealing.