PHP multi-database supported application design page 1/2_PHP tutorial

So I think that in the master-slave database design, all session-related tables should be treated specially. That is: all session data tables can be updated and queried. When a user accesses the site, the user is bound to the specified database, and all session access and query operations are performed on this database. The session table is not synchronized, and other non-session updates are also updated from the main database. In fact, this cannot escape the database switching when the session is updated, so if you don't want to bother, it is better to store the session in text.
The split-database design may improve the performance by several levels. Of course, the efficiency of a single execution will not be higher than that of a single database. After all, there is an efficiency problem in database switching. The combination of sub-databases and master-slave databases is a better solution to improve database concurrency bottlenecks. Principle: Large data volume, separate databases; large access volume, master-slave. Many times, the two work in parallel (this article does not discuss cache).
I think that if you want to implement sub-databases and master-slave relationships, the number of database servers will be very considerable. Switching to a certain server at any time in the application will be a very headache. Configuration changes, variable names, Will there be a lot of them? How to find better solutions will be the topic of this article.
First of all, there is the problem of many databases due to sub-databases. Under what circumstances will the database be branched? Maybe some people still don't understand why we need to divide the database, so I will briefly talk about my experience and speculation. For example, a blog program is generally designed to store logs in a log table. Assuming it is a multi-user blog, then a uid will be associated. If the amount of data is not large, there is no problem with this design, but when the amount of logs is huge, hundreds of thousands of log records are entered a day, and the number of visits is also relatively large. When it is considerable, I think it is impossible for every user to access the log list and find a few entries from the data table containing tens of millions of log records. The efficiency is evident. At this time, you should consider the issue of sub-library. How to divide? There is a very simple table partitioning method, that is, recording logs in each database according to the uid segment. Of course, this distribution still needs to be adjusted based on past statistical results, because the user log distribution is definitely not uniform. Set the uid segment, then index to the specified database configuration based on the uid, and create a database object. The configuration information may be as follows: