Why not let read return []*SchemaChange directly?
Return count and use changes[:count] is just a unnecessary detour

It's like an io.Reader calling convention which is caller pass-in slices so caller can reuse the previous results. Because we are in 1M tables project, I'm afraid that returning 1M []*SchemaChange (it also has internal pointers like TableInfo) will add pressure to GC.

Though it's less common, I think this package / function is the only caller of ListResult.Read. Other developers will not modify this package and will not be confused by it.

However I notice that I use json.Unmarshal on an non-empty object, not sure the leftover of the object will be overwritten or causes some problems. I'll check it tomorrow.

What was your test result?

　pass-in slices so caller can reuse the previous results

Yes, I mean the same thing, just that the code can be write as:

func f(changes []*SchemaChange) []*SchemaChange {
     ret := changes[:0]
     ret = append(ret, xxx)
     return ret
}

Anyway, this is just some personal taste, so you can choose to accept it or not.

What was your test result?

I didn't test it yet 😂 I hope other colleague can help check it. Theoretically there's no big query now.

func f(changes []*SchemaChange) []*SchemaChange {

In this new signature, the batch size of one Read is not obvious when input is nil, or it seems like an append where the slice will be grown and batch size is not be limited. Your suggestion is like EncodeBytes but here we want to control the batch size as well as reuse buffer.