Optimization of query using covering indices

一个人想着一个人 提交于 2019-12-13 05:55:13

问题


I have the following query with a subquery and self join:

SELECT bucket.patient_sid AS sid
FROM 
(SELECT clinical_data.patient_sid, 
        clinical_data.lft, 
        clinical_data.rgt
FROM clinical_data INNER JOIN 
(SELECT clinical_data.patient_sid, 
        clinical_data.lft, 
        clinical_data.rgt, 
        clinical_data.attribute_id 
FROM clinical_data 
WHERE clinical_data.attribute_id = '33' AND clinical_data.string_value = '2160-0') AS attribute 
ON clinical_data.patient_sid = attribute.patient_sid 
    AND clinical_data.lft >= attribute.lft 
    AND clinical_data.rgt <= attribute.rgt 
WHERE clinical_data.attribute_id = '36') AS bucket;

I have the following indices defined on this:

KEY `idx_bucket` (`attribute_id`,`string_value`)
KEY `idx_self_join` (`patient_sid`,`attribute_id`,`lft`,`rgt`)

When I look at the query using EXPLAIN, the subquery using the covering index idx_bucket is definitely optimized, but the self join and where clause are not. Furthermore, why does it report that only patient_sid and attribute_id are used for used_key_parts while an attachment_condition is shown for lft, rgt (what does this mean?). Both lft and 'rgt` are just defined as integers with no special properties, so why aren't they being used in my covering index?

Even more strange is when I define

KEY `idx_self_join` (`patient_sid`,`lft`,`rgt`,`attribute_id`) 

only patient_sid is registered in used_key_parts. Furthermore filtered drops to 1.60% from 11.00%!

{
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "645186.71"
    },
    "nested_loop": [
      {
        "table": {
          "table_name": "clinical_data",
          "access_type": "ref",
          "possible_keys": [
            "fk_attribute_idx",
            "idx_value_string",
            "idx_value_double",
            "idx_bucket",
            "idx_self_join_idx"
          ],
          "key": "idx_bucket",
          "used_key_parts": [
            "attribute_id",
            "string_value"
          ],
          "key_length": "308",
          "ref": [
            "const",
            "const"
          ],
          "rows_examined_per_scan": 126402,
          "rows_produced_per_join": 126402,
          "filtered": "100.00",
          "cost_info": {
            "read_cost": "126402.00",
            "eval_cost": "25280.40",
            "prefix_cost": "151682.40",
            "data_read_per_join": "46M"
          },
          "used_columns": [
            "patient_sid",
            "string_value",
            "attribute_id",
            "lft",
            "rgt"
          ],
          "attached_condition": "(`ns_large2`.`clinical_data`.`patient_sid` is not null)"
        }
      },
      {
        "table": {
          "table_name": "clinical_data",
          "access_type": "ref",
          "possible_keys": [
            "fk_attribute_idx",
            "idx_value_string",
            "idx_value_double",
            "idx_bucket",
            "idx_self_join_idx"
          ],
          "key": "idx_self_join_idx",
          "used_key_parts": [
            "attribute_id",
            "patient_sid"
          ],
          "key_length": "10",
          "ref": [
            "const",
            "ns_large2.clinical_data.patient_sid"
          ],
          "rows_examined_per_scan": 14,
          "rows_produced_per_join": 201169,
          "filtered": "11.11",
          "using_index": true,
          "cost_info": {
            "read_cost": "131327.39",
            "eval_cost": "40233.83",
            "prefix_cost": "645186.71",
            "data_read_per_join": "73M"
          },
          "used_columns": [
            "patient_sid",
            "attribute_id",
            "lft",
            "rgt"
          ],
          "attached_condition": "((`ns_large2`.`clinical_data`.`lft` >= `ns_large2`.`clinical_data`.`lft`) and (`ns_large2`.`clinical_data`.`rgt` <= `ns_large2`.`clinical_data`.`rgt`))"
        }
      }
    ]
  }
}

回答1:


Here's your basic JOIN:

SELECT

FROM clinical_data cd1

JOIN clinical_data cd2
    ON cd1.patient_sid = cd2.patient_sid
    AND cd2.attribute_id = '33'

WHERE cd1.attribute_id = '36'



回答2:


Here's what I finally came up with:

SELECT
    cd1.patient_sid as sid

FROM clinical_data cd1

JOIN clinical_data cd2
    ON cd1.patient_sid = cd2.patient_sid
    AND cd1.lft >= cd2.lft 
    AND cd1.rgt <= cd2.rgt 

WHERE cd1.attribute_id = '36'
    AND cd2.attribute_id = '33'
    AND cd2.string_value = '2160-0'



回答3:


"Used_columns" says that it is 'covering'. The final "used key parts" are not all used as a "key" because they are needed in a "range", not '='.

Get rid of the outer query:

        SELECT  clinical_data.patient_sid, clinical_data.lft, clinical_data.rgt
            FROM  clinical_data
            INNER JOIN  
              ( SELECT  clinical_data.patient_sid, clinical_data.lft, clinical_data.rgt,
                        clinical_data.attribute_id
                    FROM  clinical_data
                    WHERE  clinical_data.attribute_id = '33'
                      AND  clinical_data.string_value = '2160-0'
              ) AS attribute  ON clinical_data.patient_sid = attribute.patient_sid
              AND  clinical_data.lft >= attribute.lft
              AND  clinical_data.rgt <= attribute.rgt
            WHERE  clinical_data.attribute_id = '36'

Sorry, but the lft-rgt schema is not very efficient.



来源:https://stackoverflow.com/questions/37125283/optimization-of-query-using-covering-indices

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!