The official answer to the problem is:
There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to.
However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your definition of done?
Assuming a default 40-hour work week and two week sprint length, it would mean that the person took less than 20 minutes per ticket. That already includes the fact that that person took no breaks, no coffee sips, no restroom, not a single meeting for the whole sprint. In reality, it's probably closer to 10-15 minutes per ticket.
With our DoD, I would not be able to close a ticket in 20 minutes. I have to open it, read and understand it, do a checkout of the current code, change it, write tests for the change, prepare the data for the review/demo, commit, push, merge-request and install my code somewhere for review/demo. Even for a single character typo it takes 15-20 minutes just typing, clicking buttons and waiting for the results.
With 250 stories that are that small, I would question whether having story points for them at all is useful. Of your 251 stories in the sprint, 250 are faster done than estimated. Maybe you're better off to organize differently.
Maybe let people work on the stream of seemingly small tickets and only if they hit a particularly large one, that is elevated to a backlog item for the team. What normally happens is that a company has two teams, one for daily operations (aka 250 super small tasks) and one for development that has the focus to work on the big stories.