In the previous two issues of sharing, we introduced the SQL operators used in single-table and multi-table queries. This time, we will talk about the operators used in filtering and grouping sorting.
Filter condition: SLCT
This type of operator is relatively simple and filters the result set. What you need to pay attention to is the description information of the operator. From the description information, we can see what filter conditions are available for lower-level operations. These conditions are often the source of the optimization direction. .
What needs attention is the description part of SLCT (exp_cast(T2.ID)> 5 AND exp11 <= 0), where the content in brackets marks ID> 5 as EXP_CAST(T2.ID)> 5, ID NOT LIKE'%c %'is marked as EXP11 <= 0. Among them, the information provided by EXP_CAST(T2.ID)> 5 tells us that comparing the column ID with the number 5 is to convert the column type. In other words, even if there is an index on the ID column, the range scan may not be possible , Because the input requirement of the index range scan is the same as the type on the index column, let’s verify
Indeed, when there is an index (create indexi_index3 on t2(id)), the single-column equivalent query does not use the index to query, this is only a general principle, when comparing different types of data, one will be selected first Compare the type, and then determine the comparison method. For example, in this example, comparing ID (VARCHAR) = 5 (INT), the server preferentially chooses to convert the type to INT for comparison, so the ID column needs to be type converted, so that the index cannot be used (there is no index to store the converted data ). In this case, we need to convert the comparison object of the index column into the same format as the index column
Another condition, ID NOT LIKE'%c%', is converted to EXP11 <= 0, which actually converts NOT LIKE to INSTR(ID,'c') <= 0, the principle is not repeated here, we hope What it did is
For each of the SLCT description items, the corresponding conditions can be found in the original SQL, and see if there is a possibility of optimization
Packet: HAGR, SAGR
This type of operator is to do some processing on the fetched data, or merge or sort, and merge and sort are interoperable in some cases. Let's first look at the basic situation of these operators. There is a GROUP statement, one of these two will most likely appear
SQL> create table t4(id int,id1varchar);
SQL> insert into t4 select level,levelfrom dual connect by level < 10000;
SQL> commit;
HAGR is the most basic grouping method, HASH AGR operation, for grouping statements without optimization conditions, generally grouped in this way, the grouping principle is similar to the method of HASH INNER JOIN, the original table data is taken out, and each calculation FOLD, It is found that there are FOLDs that are the same and that meet the subsequent conditions are merged into a group (, it is not difficult to find that if the base table data is very large, the amount of calculation of HAGR cannot be ignored, then when certain conditions are met, we can use ordered Sex walking SAGR operator
SQL> create or replace index i_test4 ont4(id,id1);
The SAGR operator appears here, indicating that the output of the lower layer is sorted by the grouping column, the lower layer is SSCN I_TEST4, and I_TEST4 is the (ID, ID1) composite index, which is ordered according to the ID and satisfies the SAGR condition
SAGR, SORTED AGR operation, different from HASH AGR, because the lower layer data is ordered, the data of the same group can be taken out in order, saving a lot of calculation
Sort: SORT:
SORT is an operator used in sorting operations. We can conduct the following experiments.
As you can see, there is no SORT operator here. As mentioned above, the index I_TEST is already ordered by ID, so the sorting task has been completed in the lower SSCN. If we change a column to test.
SQL> explain select id,id1 from t4order by id1 desc;
If you are sorting the id1 column, you need to do a SORT for id1 after the SSCN, which is a lot of overhead for the database. So in actual use, we can also find ways to use the orderliness of the index to complete the sorting operation.
This is the end of the introduction to the basics of Dameng SQL optimization. In the follow-up sharing, we will also introduce you to the execution plan view and indexing knowledge, so stay tuned!
[Dry goods sharing] Dameng SQL optimization-basic articles
[Dry goods sharing] Dameng SQL optimization-basic articles (2)