Domanda

Look at this 1st scenario, you got a table that has 2 columns- Parent (P) & Child (C).

P-C
1-3
2-8
3-6
6-4
8-7

When users search for all descendants of "1" then it will show:

P-C
1-3
3-6
6-4

& When users search for all descendants of "2" then it will show:

P-C
2-8
8-7

This is the Mysql query to get the Data

select distinct col1
from (select col1,
             @pv:=(case when find_in_set(col2, @pv) then @pv else concat(@pv, ',', col2) 
                   end) as 'col2'
      from table1 join
          (select @pv:='1') tmp
          on find_in_set(col1, @pv) > 0
     ) t

Ok, you know that Database indexing is to index the column so that the DB can look up DB faster than without indexing.

However, in the 1st scenario mentioned above, "Do you think DB indexing play any important role in Parent Child table?"

Ok, if the users search for all descendants of "2", then the DB first found "2-8", then it has to jump over 2 records before it found the next child "8-7".

This is the simple example, but what if there're thousands of records located far away from each other (or position of data is very fragmented), then "How DB (assuming that the Parent-Child column got indexed) can look up data quickly in the 1st scenario?"

But if we make all the descendants sit next to each other like in this 2nd scenario:

P-C
1-3
3-6
6-4
2-8
8-7

then "Will DB (even we don't index Parent Child column) look up data faster in the 2nd scenario than the 1st one?"

Note: If you reverse the order of the descendants like this:

P-C
6-4
3-6
1-3
2-8
8-7

& if you search for "1" then it will show only "3", it won't show "3-6" & "6-4" since "3-6" & "6-4" are not in the continuous order. It means that the MYSQL, when running the above query, will search the record from the top to down. So it means that Mysql won't search for the next descendants from the beginning, -> Do you think so?

Note: Pls also read this link @ Symbol - a solution for Recursive SELECT query in Mysql?

È stato utile?

Soluzione

With your data as such

P-C
1-3
3-6
6-4
2-8
8-7

MySQL will find 5 records and assuming that it chooses to return them in this order (it could return them in the order of the prices of items 1, 3, 6, 2 and 8 on the menu in the Oracle canteen today):-

The first record is 1, and it will store 3 (ie, the child) in the variable pv. It will then get the next record. This is record 3 and it will see if that is stored in pv and finding it, 6 will be concatenated onto the end of pv. It will then get the next record (6 in this case), check if 6 is stored in pv and as it is concatenate 4 onto the end of pv. It will then get the next record (2 in this case), check if 2 is stored in pv but as it isn't it will ignore it. It will then get the next record (8 in this case), check if 8 is stored in pv but as it isn't it will ignore it.

It will continue to process every single record on the table whether you want them or not. It will not use any indexes to do any of these checks, or to stop processing until it gets to the end of all the records.

MySQL (and relational databases in general) are designed to get sets of data, and work well for comparing one set with another set. The above query is getting a single set of data (potentially hideously large) and going through every returned record in a random order (which you hope is the order you entered them in) checking each one against a variable it is building up.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top