Sub database and sub table

As mentioned above, most business scenarios are more reading and less writing , Of the query qps Much higher than writing . So when the query performance of the business decreases , Consider using master-slave read-write separation . This will indeed ease for a long time , It's like the calm of wisdom teeth after anti-inflammatory , But if you don't pull out your wisdom teeth, one day you will not be able to stand the pain of repeated inflammation , Business, too . After the performance bottleneck of query is alleviated , Write performance degradation often comes with , And it came more violently , The amount of data has skyrocketed , Inquiries will also be implicated . To solve the problem of writing , Smart humans have used the trick of dividing the database and tables .

There are actually two things about dividing the database and tables , But the idea is to solve the uncontrollable growth of single table data volume by adding several main databases . You can't fight alone , You can call and shake a car of people , This is the core idea .

First of all, the sub database is relatively low , Take out some business intensive forms to form an independent library to provide operations . For example, user table , A table with a large amount of data in the core scenario of order table , One library is split into two .

In this way, one is divided into two , It can significantly relieve the connection pool pressure of a library . But the amount of data in a single table is still so large , The pressure of inquiry has not been relieved , Even if there is an index, it will still be slow .

Optimize for the purpose of reducing the amount of data in a single table , Naturally, we will think that we can split according to the characteristics of table fields . The most used... At present 2 The first plan is ：

Complex systems must have more problems than simple systems , The introduction of sub database and sub table will inevitably bring more problems . First of all, you must be able to use it , Otherwise, it may backfire . First , Now that you've divided N Databases , When querying data, you must bring a field that can be quickly indexed to the corresponding library . Whenever there is a cross library, the performance will plummet . So at this point , We need a partition key to tell us which library to check . The partitioning key in the first case is uid, But if you want to use name Check or get the corresponding uid, At this time, you even need a mapping table , This mapping table can also be sub database . The disadvantage of sorting libraries by time period is that you should remember to create new libraries , If you don't remember the business, you hang up .

Sub database and sub table is a conventional technology , My advice to this is ：