来看一条sql:
SELECT m_id ,is_tax_paid FROM merchandise WHERE m_id > 10 AND last_update_time < NOW() ORDER BY m_id LIMIT (pageNum-1) * pageSize,pageSize
merchandise表的m_id和last_update_time都加了唯一索引,当然,这里不是组合索引。
初一看,这条sql没有任何问题,但在线上跑了一阵子之后,有严重的性能问题,单次查询要3秒左右,被记录成慢sql。
原因是merchandise表太大,线上有1亿多行数据,当页数太多的时候,mysql的limit分页要检索的数据太多了,具体要看下mysql的B+树索引是怎样查数据的。
知道原因了,改进的方法,只需要按id来分页,每次查询的时候,指定id的大小,然后再limit,如:
SELECT m_id ,is_tax_paid FROM merchandise WHERE m_id > ? AND last_update_time < ? ORDER BY m_id LIMIT pageSize
每次循环的时候从查出的结果里找到最大的m_id,把它传给下次的sql查询。上面的 m_id最好是唯一索引,主键索引,最好。
long updateBeginMid = 19541094l; while (true) { List<MerchandiseIsTaxPaid> midIsTaxPaidPairs = vipGoodsDao.listMidByLastUpdateTime(lastMigrateUpdateTime,updateBeginMid, BATCH_SIZE); doSomething(midIsTaxPaidPairs); if (CollectionUtils.isEmpty(midIsTaxPaidPairs) || midIsTaxPaidPairs.size() < BATCH_SIZE) { break; } else { int size = midIsTaxPaidPairs.size(); MerchandiseIsTaxPaid merchandiseIsTaxPaid = midIsTaxPaidPairs.get(size - 1); updateBeginMid = merchandiseIsTaxPaid.getMerchandiseNo(); // 每次查询从最大的更新id开始查起 } }
也可以参考这里:
http://database.51cto.com/art/201005/200395.htm