To properly design the microservice(s), you need to step back and look at things from a higher level. It's not enough to identify what components you have and what ones you may need to build; you need to consider how and why each component is used and how they relate to other components.
Imagine you live in a one bedroom apartment but will soon move to a much larger house. You have five pieces of furniture in your living room you would like to keep and need to decide what room(s) to move the furniture to. Would you move each piece of furniture to a separate room in the house or would you move them all to the same room? (Pause for a moment to consider how silly that question might sound.) Presumably, the rooms you choose would depend on what those pieces of furniture actually are.
If two pieces of the furniture are a couch and a TV stand, you would likely move them to the new living room so you have a place to sit and watch TV. You might also move the floor lamp to the living room depending upon how much light there is. However, your kitchen table wouldn't need to be in the living room since you would now have a full sized kitchen to put it in. Likewise, your coat rack would go in the foyer of your new house since that's where the front door is.
This is the same approach you should apply to your new microservice(s). What do these stored procedures do? How are they used and how do they relate to each other? If they are all closely related and see similar levels of use, then it would make sense to put only one microservice in front of them. If, however, those stored procedures have nothing in common aside from being in the same database, then it would make sense to create five separate microservices; if you do so, though, you should also discuss splitting the database into smaller pieces as well.
There are many possible ways you could design microservices. The key is to organize the functionality into services where the internal components are closely related but the external components are loosely related (if related at all). This will make the services easier to comprehend and thus easier to maintain. It will also minimize dependencies, making it easier to scale services as you need to.
In short, the ratio of microservices to stored procedures is irrelevant. What matters it that functionality is organized logically. Otherwise, you'll end up in weird scenarios like having a TV you can't sit in front of or a coat rack that isn't anywhere near a door.