Is it highly efficient to create a Table for each user using mysql for online synchronization of a large number of user history records, or to identify different users using UID in a Table?

Efficiency ...... Refer to the SAE billing method. The cheaper the better. Sae.sina.com.cn? Mdevcenter & amp; catId155 efficiency ...... Refer to the SAE billing method. The cheaper the better.
Http://sae.sina.com.cn /? M = devcenter & catId = 155. Reply content: neither of them is good. You can use uid-based hash to split tables or timeline-based hash to split tables. View specific requirements and definitions
Which order of magnitude is this "massive"? 10 thousand, 100,000, million, ten million? About the data size of each user

What are the proportions of active users and non-active users? What is the data read/write ratio? Is it a large number of reads, a small amount of writes, or regular writes but few reads?

What functions do you want to provide? If you simply store and read historical records, you can consider the Key-Value database. If you want to perform analysis, will there be cross-user queries?

These situations may be unclear, but you should consider them first.

However, intuition tells me that a large number of users of the landlord will not go anywhere, so how to design it should be able to fit into the specifics depends on the features you need to implement, the design architecture, and the number of users.

If you implement different complex functions for a large number of users, it is better to create an independent table for each user. In this way, users can be distributed to different Mysql servers based on their IDs or regions to facilitate optimization, management, and fault tolerance.

If you only plan to have a small number of users and data and functions, and take the price as the benchmark, and the data can be processed by one server, then the two upstairs are true. Too many tables or too many columns will affect the efficiency.
Creating a table for each user is generally not used in the design.