Author: Yang Taotao
Senior database expert, specializing in MySQL for more than ten years. Good at MySQL, PostgreSQL, MongoDB and other open source database-related backup and recovery, SQL tuning, monitoring operation and maintenance, high-availability architecture design, etc. Currently working in Acson, providing MySQL-related technical support and MySQL-related course training for major operators and banking and financial companies.
Source of this article: original contribution
*Produced by the Aikesheng open source community, the original content is not allowed to be used without authorization, please contact the editor and indicate the source for reprinting.
In terms of the relationship between the index and the main table, OceanBase has two types of indexes: local indexes and global indexes.
A local index is equivalent to what we usually call a local index, and maintains a one-to-one relationship with the data structure of the main table. The local index does not have the concept of separate partitions. Generally speaking, the partition method of the main table determines the partition method of the local index. That is to say, if the main table has 10 partitions, then for each partition, there is a corresponding local index .
Different from local indexes, global indexes maintain one-to-many and many-to-many relationships with the data structure of the main table. Global indexes are mainly used in partitioned tables. For a partitioned table, a non-partitioned global index corresponds to multiple partitions of the main table; a partitioned global index also corresponds to multiple partitions of the main table, and each partition of the main table also corresponds to index partitions of multiple global indexes.
The goal of introducing global indexes is to make up for some deficiencies in data filtering of local indexes, such as avoiding full partition scans of partitioned tables, and pressing filter conditions to matching table partitions.
For query filter conditions, the simple usage scenarios of local indexes and global indexes are summarized as follows:
1. For queries with partition keys, local indexes are suitable. This is also the original intention of the partition table design, and the design of the partition table is deduced by filtering conditions.
For example, the statement: select * from p1 where id = 9; id is the partition key, you can directly locate specific table partitions (p9), and only need to scan one row of records.
<mysql:5.6.25:ytt>explain select * from p1 where id = 9\G
*************************** 1. row ***************************
Query Plan: ==================================
|ID|OPERATOR |NAME|EST. ROWS|COST|
----------------------------------
|0 |TABLE GET|p1 |1 |46 |
==================================
Outputs & filters:
-------------------------------------
0 - output([p1.id], [p1.r1], [p1.r2]), filter(nil),
access([p1.id], [p1.r1], [p1.r2]), partitions(p9)
1 row in set (0.005 sec)
2. There are two considerations for queries without partition keys, mainly whether they can overcome the shortcomings of global indexes: global indexes will inevitably bring about distributed execution of queries!
(1) The concurrent writing of the table is not large, and global indexes can be considered.
(2) The concurrent writing of the table is very large, and whether to use the global index is still open to discussion. You can do a stress test based on the current business model and take a compromise point.
For example, the following statement, the global index idx_r2_global is based on the non-partition field r2, and the execution plan is as follows: Operator 1 needs to go to the underlying nodes for distributed scanning (DISTRIBUTED TABLE SCAN).
<mysql:5.6.25:ytt>explain select * from p1 where r2 = 30\G
*************************** 1. row ***************************
Query Plan: =============================================================
|ID|OPERATOR |NAME |EST. ROWS|COST|
-------------------------------------------------------------
|0 |TABLE LOOKUP |p1 |101 |395 |
|1 | DISTRIBUTED TABLE SCAN|p1(idx_r2_global)|101 |48 |
=============================================================
...
3. For businesses that need to establish a unique index on a field that is not a primary key or a partition key, there are two considerations:
(1) Create a local index for this field, but you need to bring the complete partition key. This method is not recommended. First, it is necessary to change the filter conditions and increase the partition key; second, it increases the data redundancy of the index itself.
For example, creating such an index under a MySQL tenant will result in an error:
<mysql:5.6.25:ytt>create unique index udx_r1 on p1(r1) local;
ERROR 1503 (HY000): A UNIQUE INDEX must include all columns in the table's partitioning function
If you create a local index, you need to add the full partition key:
<mysql:5.6.25:ytt>create unique index udx_r1_local on p1(r1,id) local;
Query OK, 0 rows affected (3.012 sec)
(2) To create a global index for this field, there is no need to bring a complete partition key. Highly recommended way!
<mysql:5.6.25:ytt>create unique index udx_r1_global on p1(r1) global;
Query OK, 0 rows affected (1.950 sec)