Transaction conflicts on membership cron

A customer identified a problem today where they renewed a membership but 2 minutes later the customer was updated by CiviMembership cron & changed to being in Grace. The end_date & membership_type changes were reverted.

The database has 90,000 memberships, 38,000 of which are current or expired less than 2 years ago. When the membership cron runs it inspects all 90,000 memberships & takes several minutes to run. In this case the membership was edited after the 90,000 memberships were loaded into memory - but before the record in question was processed - resulting in the old values being resaved, along with a status change.

The situation seems to be fairly rare - as people would need to be renewing right at the end of their membership for it to kick in.

On the site in question I'm changing the cron to run daily rather than the default of hourly which was probably part of the problem.

I expect that the answer is to refactor the cron into a smaller queries or batches but a small win might be gained by simply not loading up those memberships whose expired well in the past. It seems that there are 3 jobs in play
1) updating deceased memberships
2) updating memberships not set to override
3) sending renewals

if the first used it's own query then past memberships wouldn't be required for #2 & #3.

NB setting this to future version as no current sponsor.