Concerns about mysql table sharding

If there is a user table, the data volume is large, and the table needs to be split. Perform table sharding based on the user ID, and store the remaining 10 objects. But now I have some concerns. When a user logs on, they cannot query 10 tables. Do you have any good suggestions or ideas? Let's discuss them, learn from each other, and join each other... if there is a user table, the data volume is large, and we need to split the table.
Perform table sharding based on the user ID, and store the remaining 10 objects.
But now I have some concerns. When a user logs on, they cannot query 10 tables.
Do you have any good suggestions or ideas? discuss them, learn from each other, and make progress !!!

Sorry is not clearly described.

User table, id, name, and password fields
Now the table sharding by id has been performed, but the name and password must be verified during login. How can this problem be solved? You should not check every table.

Reply content:

If there is a user table, the data volume is large, and the table needs to be split.
Perform table sharding based on the user ID, and store the remaining 10 objects.
But now I have some concerns. When a user logs on, they cannot query 10 tables.
Do you have any good suggestions or ideas? discuss them, learn from each other, and make progress !!!

Sorry is not clearly described.

User table, id, name, and password fields
Now the table sharding by id has been performed, but the name and password must be verified during login. How can this problem be solved? You should not check every table.

Check out my blog.

Http://edagarli.logdown.com/posts/345292

There is no need to directly operate on the database, and the User data can be stored in the cache to query the cache.

You can use the user name for hash.

After MySQL5.5, you can select partitions by month.

If table sharding is selected, the userid value is a little large for 10 form tables with the remaining 10 points. If the remainder of userid is set to 1, the userid can be retrieved from user_1, and so on.

If there are not enough 10 tables, you can select partitions or hash N tables. N is determined by your own algorithm.

I personally think that division by ID is not conducive to subsequent database expansion. If 10 are not enough, it is necessary to extend to 15 clients to be modified, the hash method is more reliable.
Append: otherwise, you can add the redis ing between the redis. redis Record name and ID in front of the database to avoid global search to a certain extent.

It is best to divide user tables vertically. You can use memcache or redis to cache user tables. horizontal segmentation is of little significance.

Use the cache, because you do not know the user ID at the time of logon.

I don't understand why you split tables into User tables. For example, it may mislead people.
The sub-tables I have tried are generally divided by time.
If you want to use the User sub-table, we recommend that you use the first letter of the User name, each letter is a sub-table. If there are too many tables, put a table on abc, and put a table on def, take the first letter of the query, and then determine the corresponding table shard.

It is much easier to use a user name in English.