Home/ Questions/Q 8369147
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T13:34:27+00:00

I have a table which stores highscores for a game. This game has many

  • 0

I have a table which stores highscores for a game. This game has many levels where scores are then ordered by score DESC (which is an index) where the level is a level ID. Would partitioning on this level ID column create the same result as create many seperate level tables (one for each level ID)? I need this to seperate out the level data somehow as I’m expecting 10’s of millions of entries. I hear partitioning could speed this process up, whilst leaving my tables normalised.

Also, I have an unknown amount of levels in my game (levels may be added or removed at any time). Can I specify to partition on this level ID column and have new partitions automaticaly get created when a new (distinct level ID) is added to the highscore table? I may start with 10 seperate levels but end up with 50, but all my data is still kept in one table, but many partitions? Do I have to index the level ID to make this work?

Thanks in advance for your advice!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Creting an index on a single column is good, but creating an index that contains two columns would be a better solution based on the information you have given. I would run a 

    alter table highscores add index(columnScore, columnLevel);

    This will make performance much better. From a database point of view, no matter what highscores you are looking for, the database will know where to search for them.

    On that note, if you can, (and you are using mysami tables) you could also run a:

    alter table order by columnScore, columnLevel;

    which will then group all your data together, so that even though the database KNOWS where each bit is, it can find all the records that belong to one another nearby – which means less hard drive work – and therefore quicker results.

    That second operation too, can make a HUGE difference. My PC at work (horrible old machine that was top of the range in the nineties) has a database with several million records in it that I built – nothing huge, about 2.5gb of data including indexes – and performance was dragging, but ordering the data for the indexes improved query time from about 1.5 minutes per query to around 8 seconds. That’s JUST due to hard drive speed in being able to get to all the sectors that contain the data.

    • 0