1、情景:统计不用应用的使用数据,例如接入量、设备量、用户量 。
由于统计用户量的表user_account和统计设备量的表device不在同一数据库,而且表数据量很大(几十万、上百万条)(gass平台所以数据量较大),如果每次调用该接口都执行sql的话根本不现实。
方法:将各应用的设备量、用户量、接入量,每天定时统计一次@schedule(可以在凌晨),并存储在redis中(例如快递应用的用户量为ab_user_amount,设备量ab_device_amount ),这样每次调用该接口时,就会从redis中查询
2、当查用用户的收益时(一个用户开通一个应用,拿这个应用的所有盈利会属于该用户)
统计用户收益时会查询record_user_pay表
之前的写法:
<!-- 我的收益:按月统计收益 --> <select id="countMarketAppMoneyByMonths" parameterType="java.util.Map" resultType="java.util.Map"> SELECT Date_format(end_time, '%Y-%m') AS months, SUM(pay_total_fee) AS moneys FROM record_user_pay WHERE market_id = #{marketId} AND market_appSign = #{marketAppSign} AND (pay_dType = 1 OR pay_dType = 2 OR pay_dType = 5) AND pay_status = 1 AND end_time >= #{startTime} AND end_time <= #{endTime} GROUP BY months </select> |
问题:由于record_user_pay表数据量较大(几十万),而且会有几种统计方式,包括近一周、近一个月、近半年,如果每次都查询该表的话,查询时间较长 。
解决方法:新建一张表user_benefit, 记录是每个用户每天的数据 。这样每条记录就是每个用户每天的数据,如下:
id | user_id | benefit | benefit_date |
1 | 100001 | 100 | 2019.10.1 |
2 | 100001 | 100 | 2019.10.2 |
3 | 100002 | 70 | 2019.10.1 |
这样如果查询用户近7天的收益,只需要从user_benefit查询(数据量简化到几千条)
3、例如在查询记录列表时,如果数据量较大,
那可以在查询时,如果没有指定条件,可以有默认查询前20条记录 。
扩展:
https://blog.csdn.net/phmiscro/article/details/53896608
由上可见在数据量很大的情况下,适当的使用LIMIT 1对查询操作的优化效果还是相当明显的。
注意:如果以上表字段中username被设置为了索引的话,这个时候使用LIMIT 1在查询速度上没有明显的效果。