I don't know if this is doable in MySQL, but table partitionning can be useful, and even bring up faster performances. Let's consider a geographical application where you store the people's adresses for the 48 contiguous lower states.
You would then have what we might call a base table which would be partinioned into 48 other tables, one for each state.
Depending on your partition definition, this base table, upon SELECT, "knows" what table to query against in order to have the required information data depending on what state is queried. It's like an intelligent interface that you might query, and the query is simply redirected to the right underlying table, without letting the user know about this underlying table.
Careful here, I'm absolutely not talking about creating VIEWs, but partitioning data TABLEs, which is very different.
In the end, partitioning used this way is to get better performance.
Now, we're facing a 5 000 000 rows data table here. This shouldn't hurt the performance much if INDEXes are suitable for the query needs. You should perhaps look for optimizing the INDEXes first. Afterwards, if some performance issues are still present, consider partitioning your table based on a discriminating value.
Here's some details about partitioning database tables in SQL Server, this might give you some guidance as for MySQL. And
here's an interesting article about performance partitioning in MySQL.