Do a large number of users of the history of online synchronization, with MySQL, is for each user to build a table high efficiency or in a table with the UID identification of different users of high efficiency?

The so-called efficiency ... See SAE Fee method. The less expensive the better.
/ http sae.sina.com.cn/? m=devcenter&catid=155

Reply content:

Two are not good, can be based on the UID hash table or based on the time line hash table. See the definition of specific requirements
What is the order of magnitude, 10,000, 100,000, million, tens of millions? How big is the amount of data per user?

What is the ratio of active and inactive users? What is the reading and writing ratio of the data, is it a lot of reading a small amount of writing, or is it often written but seldom read?

What features are available? If you are simply storing and reading history, consider Key-value database, if you want to do analysis, will there be cross-user queries?

This may not be clear, but consider it first.

However, the intuition tells me that the landlord of a large number of users will not be big to where to go, so casually how to design should be able to do exactly what you need to achieve the function and design structure and number of users.

If you are implementing different users ' complex functions for a large amount of users, it is better to build separate tables for each user. This allows users to be distributed across multiple MySQL servers based on their ID or region, which facilitates optimization, management, and fault tolerance.

If only a small number of users and data and features are planned and priced, and the data can be processed by a single server, the two above are true. Too many tables or too many columns can affect efficiency.
Building a table for each user is generally not used in the design.

