I think there is another way, that is, to create a general comment table. The fields of this table do not have to be the same as the sub-table. The most important thing is to comment on id, and creation time. The backend management can read this summary table, and the comment details field can be queried by table.

for example, 50 records on a page, up to 50 other queries, go to separate tables to query detailed data, although there are more queries, it will not cause much pressure to be used in the background management system.

I suggest a curve method to save the nation. Don't break down the table by userid. It's tiring. It's tiring to make a monthly table according to the comment time. Our experience is that if there are no more than 20 million pieces of data per table in Mysql, it will be much more convenient to summarize. The only thing you need to pay attention to in background management is the problem of pagination.

even if I throw a brick to attract jade, I hope I can help you.

Update: flc1125 mentioned the problem of load. The best I can think of is to add redis cache. I would also like to ask what is the main query business of this comment? Is it a recent comment showing an article?

first of all, your table splitting method is correct. Secondly, add a synchronization table. The data of this table retains the comment data of the last X days, the data source is composed of other 100 tables with federation; the data operation is done by Synchronize on a regular or mq basis. This table is only used for backend use (or businesses with small concurrency)

create a new table, and update the table at regular intervals. For example, if the page loads 30 comments at a time, 30 pieces of data will be found at a time and taken from here when the page is loaded.