Generally, when MySQL single-table data is 2000W, it is necessary to consider sub-database and sub-table. Because, from the top, the query effect decreases more obviously.
However, the points table is good, and the points are also very good. However, cross-table Join or combined query after table splitting becomes a headache. Today, let's take a look at several common cross-table Join problems.
1. Multi-table backup of dictionary tables or global tables to avoid cross-table and cross-database Join queries.
A major feature of relational databases is associative query. The use of sub-database and sub-table is originally a separate query. Let me talk about a simple situation first, that is, the dictionary table. The data itself is very small, so you can sub-tabulate it. The amount of data is too small to be necessary at all. Regardless of the table, the associated table, for example, the dictionary table associated with the order table requires Join. If you split the tables, then there will be cross-table association problems, and the amount of data is small, and the business complexity increases. Regardless of the table and database, the data may be concentrated in the same database and table. Join, a large amount of query traffic may be concentrated in a certain database, but it may be dragged down.
Therefore, for dictionary tables or other global tables. In order to avoid cross-database join queries, we can save a copy of this type of table in every other database. At the same time, this type of data is usually rarely modified (or almost never), so there is no need to worry too much about the "consistency" issue.
2. Anti-paradigm design to avoid cross-database Join query.
This design is very common in e-commerce. For example, I have an order table, each record in the order will be associated with the seller's id and the seller's Name. The advantage of this is that, many times, when displaying the seller information in the order, I don't need to cross-table and cross-database Join.
3. Reasonable business design to avoid cross-table and cross-database query.
The most common problem of this kind is my order. When I want to check all my orders, I hope that one table can be done, no need to cross tables. In other words, when designing, try to put the orders of the same user in the same table. When dividing the table, consider dividing according to the user's id.
4. Use offline computing and streaming technology to avoid cross-table and cross-database queries.
I will now cite an example of a report query. In this case, it may be necessary to span N tables, and there is no way to avoid it. But from the design, we should try to avoid Join. If there are multiple joins, either the design is unreasonable or the technology selection is wrong.
The real-time requirements of the report type query are not high, so you can use offline analysis and other means. Reporting systems were implemented through OLAP data warehouses in the traditional BI era, but now they are implemented more by means of offline analysis, streaming computing, etc., instead of directly executing a large number of joins in the business database as described above. And statistics.
Above, 4 points, what I said is very simple. In fact, cross-table and cross-database will bring many problems. For example, transaction issues; if it is simple not to cross the table, a comment can be done, but after the table is divided, it will be more troublesome. Other issues include cross-node count, order by, group by, and aggregation functions.
As the amount of data increases, the complexity of the business also increases proportionally. The technical problems that you used to solve in one hour, now if you have no experience, it may be difficult to do so!