06｜谋定后动：秒杀的流量管控

可以放在redis里，list分页取数据还是很快的，我们现在一个list就存了几百万的数据，速度还是可以的，如果想更快的话可以多用几个key，发送的时候可以用多线程

按id主键循环limit 100，顺序查出来再发送，还有就是当预约成功后，把预约提醒任务放到MQ里？

单sku 预约几百万用户，可以推测这张表的数据量肯定会很大，可以考虑分库分表优化； 单就本条SQL和发送推送的场景而言，可以考虑利用索引进行优化： SELECT user_name FROM t_reserve_user WHERE sku_id = #{skuId} and id>(#{page.index}-1)*#{page.step} limit #{page.step} #{page.index}表示当前页码 如果这条SQL语句达不到要求还可以考虑添加一些索引。

根据主键id 查询 select user_name from t_reserve_user where id >? and id<? 按规定的offset 查询 如: offset =10000 1.select user_name from t_reserve_user where id >0 and id<=10000; 2.select user_name from t_reserve_user where id >100000 and id<20000;

where sku_id > max_id。可以让sku_id是自增主键，每次查询下一页都带入上一页最大id。 另外是不是可以让ES去干这事情

1. 什么是深度分页问题? (1) MySQL 走 B+ 索引的复杂度为 O(log n), 所以 `where sku_id=#{skuId}` 的性能没问题的 (2) `limit #{page.beginIndex},#{page.step}` 会导致 MySQL 从第一条数据开始扫描, 扫描到 `beginIndex` 之后, 再取 `step` 条数据, 这个过程的复杂度为 O(n) MYSQL 是基于硬盘的, 每页大小默认是 16KB, 也就是说每次读取的数据是 16KB, 如果顺序扫描 1000W 数据, 会产生大量的 IO, 就会非常慢 (你可以试试一些网站指定巨大偏移量的分页, 可能会卡死) 1. 解决方法 (1) 分库分表: MYSQL 单表推荐不要超过 500W 数据, 数据过大就应该分库分表 (2) 使用索引确定范围: job程序分页不是随机分页的, 一般是一页一页扫描, 可以使用上一次查询的索引最大值来规避数据的扫描, 例如: ```sql select user_name from t_reserve_user where sku_id=#{skuId} and id>#{lastId} limit #{page.step} ``` (3) 使用缓存: 例如 redis list 来分页 MYSQL 深度分页的性能慢主要有 2 个原因: * 1 是 O(n) 时间复杂度 * 2 是 多次磁盘 IO 使用内存, 比如 redis 可以规避多次磁盘 IO

如果非要用mysql的话 建立sku_id + user_name的联合索引 每次查询都记录下最后一个user_name select user_name from t_reserve_user where sku_id=#{skuId} and user_name > ${userName} limit #{page.beginIndex},#{page.step} order by sku_id, user_name

请教老师，文中的“对于历史数据，也需要有个定时任务进行结转归档，以减轻数据库的压力”，这个“结转归档”具体是怎么做的？是说把历史的预约数据转存到其他地方进行冷备，然后把历史数据从预约表中删除掉是吗？