Home/ Questions/Q 646323
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T21:35:56+00:00

I’m trying to build out a mysql database design for a project. The problem

  • 0

I’m trying to build out a mysql database design for a project. The problem is coming up with the best solution. Basically in my application, I will have to insert approximately 10-30 rows per user. The primary key will be a random CHAR(16) string. There will also be an datetime index, and an additional row (with an index) called “data”.

Day to day, there will only be a heavy amount of inserts and lookups on the table. The lookups will always joined based on the primary key (so joining those 10-30 rows per user).

I will at times need to be able to look at a few specific months (or a full year even) and use mysql GROUP BY functions on the “data” index as well.

At its current volume and estimates, I would expect the table to grow 9.3m rows/month. I do expect this to increase.

So my question comes down to this: mysql partitions, programmatic table separation, or another solution? and are things best separated by month or year? We are running on RHEL, so getting mysql 5.1 may be a bit of work, but if that’s a better solution it may be worth going for.

innoDB has already been selected for this project. Day to day performance is the primary concern.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Partition the data on the dates (and maybe additionally the user it is per-user data and you have lots of users).

    Then create a monthly table with the SUM, COUNT, AVG, etc that you need and the appropriate group by. You can partition that table as well (but dates probably won’t be a meaningful partition)

    Then create a yearly table like the monthly table.

    Populate the monthly and yearly tables with REPLACE INTO ... SELECT ... statements.

    • 0