一张表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.*

如果对limit 1000要求不多
直接按order_time分段呗，比如每小时的数据处理一次
--
FROM 111.197.115.*

也行, 不过有热点小时数据
【 在 hothail 的大作中提到: 】
: 如果对limit 1000要求不多
: 直接按order_time分段呗，比如每小时的数据处理一次
--
FROM 114.252.54.*

热点小时肯定的要考虑的
硬抗，或者按时间继续分
或者回到按条数处理的方法，都行
甚至如果可以的话，用消息mq处理也可以考虑
【 在 ota 的大作中提到: 】
: 也行, 不过有热点小时数据
※ 修改:·hothail 于 Apr  4 18:34:29 2021 修改本文·[FROM: 111.197.115.*]
※ 来源:·https://exp.newsmth.net·[FROM: 111.197.115.*]

修改:hothail FROM 111.197.115.*
FROM 111.197.115.*

多谢指正, 要加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.*