- 主题:问个分批处理的sql问题
一张表1000w条数据, 每天生单会insertOrUpdate 50w条,
需求期望要select出生单时间是昨天的所有数据做处理.因为数据有点多,所以想用limit分批取.
生单时间做了索引,
方案1.
select * from tbl where order_time > '上次最后一条数据的order_time' limit 1000
这个问题是, 如果第1000条和第1001条的order_time相同,会把第1001条数据丢掉.
方案2.
2-1. 先通过生单时间索引, 找到最小id和最大id,
2-2. select * from tbl where id >= minId and id <= maxId id > 上次的最大id limit 1000
2-3. 2-2的结果在代码中通过生单时间过滤
改走id索引.
这个问题是, 最坏情况下, minid=表的最小id, maxId=表的最大id, 会扫全表,中间很多无效查询
方案3.
临时表,没研究过
一次性50w条数据放临时表的成本大吗?
--
FROM 114.252.54.*
我觉得可以,
幂等不去重,
报表的操作不幂等需要去下重.
和同事对,被嫌弃不够有悠亚, 但又没给出更佳方案
【 在 javafish 的大作中提到: 】
: 第一种大于改成大于等于
: 再排个重呗
: 要一句搞定就是and id <> (ids)
: ...................
--
FROM 114.252.54.*
也行, 不过有热点小时数据
【 在 hothail 的大作中提到: 】
: 如果对limit 1000要求不多
: 直接按order_time分段呗，比如每小时的数据处理一次
--
FROM 114.252.54.*
多谢指正, 要加order by的.
mysql默认不保证顺序哈
方案1的时间, 因为业务原因, 时间不是个时间戳, 秒下的精度丢掉了.
比如通过string转的时间, '2021-01-01 11:11:11'
【 在 Mikov 的大作中提到: 】
: 按方案1,
: 如果用的mysql, 5.6.4之后的版本支持datetime(3), 产生同样时间值的概率几乎为0, 要求精确可以用 >= 再排除
: 方案2,
: ...................
--
FROM 114.252.54.*
嗯可以解决批量更新update time落在同一毫秒的问题对吧
不过我这边一个case，根据业务时间来检索，这个时间有索引，但可能是很早之前插入的没更新过
【 在 agedloser 的大作中提到: 】
--
FROM 114.242.250.*