Real MySQL Chapter 6: Execution Plan Analysis Summary

Sun, 12 Sep 2021 00:00:00 +0900

This exposition examines execution plans and index utilization across diverse scenarios in comprehensive detail.

6.1. Overview

Execution Plan Definition

The optimizer formulates optimal execution strategies by consulting statistical information regarding data distribution across tables to devise optimal execution plans for query execution.

Query Execution Phases

Parse SQL statements into MySQL server-comprehensible components (SQL parsing)
Examine parse tree to determine table reading sequence and index selection (optimization and execution plan formulation by optimizer)
Retrieve data from storage engine according to selected sequence and indices

Optimizer Categories

Most RDBMS systems, including MySQL, employ cost-based optimizers
- Generate multiple feasible approaches for query processing, calculating costs for each execution plan utilizing cost information for unit operations and predicted statistical data for target tables
Rarely employed rule-based optimization exists (establishes execution plans according to optimizer’s built-in priorities. Excludes statistical information such as record counts and column value distributions)

Statistical Information

Approximate record counts, unique value quantities in indices, et cetera
Statistical information proves significantly inaccurate for small record counts. Occasionally necessitates forced renewal via analyze command
- analyze command: Updates index key value distribution (selectivity)
Statistical information collection reads only 8 randomly selected index pages or quantity specified by innodb_stats_sample_pages parameter

6.2. Execution Plan Analysis

Update, insert, delete statements lack execution plan verification methods. Create select statements with identical where clauses for verification

Execution Plan Column Descriptions

id column: Each select statement receives distinct id
select_type column
- SIMPLE: Simple select without subqueries, et cetera
- PRIMARY: Outermost query in statements containing unions or subqueries
- UNION, DEPENDENT UNION, UNION RESULT
- SUBQUERY: Subqueries used outside from clause
- DEPENDENT SUBQUERY: Subqueries utilizing columns defined in outer select. Outer query executes first → subquery execution. Performance degradation
- DERIVED: Subqueries used in from clause
- UNCACHEABLE SUBQUERY, UNCACHEABLE UNION
table column: Execution plans display per table rather than per unit select query
- <derived> or <union> within angle brackets indicate temporary tables
- Identical ids: Upper lines constitute driving tables. Driving tables are read first for driven table joining
type column: Indicates record reading methodology for each table
- const: Unique index scan. Query processing returning precisely one record utilizing PK or unique key columns in where clause
- eq_ref: For join queries. First-read table column values equal-compared with next table’s PK or unique key
- ref: Equal condition searching regardless of joins or constraints
- range: Index range scan! Index searched with ranges rather than single values
- index_merge: Multiple index utilization
- index: Index full scan (reads entire index)
- ALL: Full table scan - most inefficient
key column: Final selected index displayed
rows column: Shows approximate record quantities in target tables
extra column: Performance-related statement displays

6.3. MySQL’s Principal Processing Methodologies

6.3.1. Full Table Scan

Conditions include: extremely small table record counts, absence of index-utilizable conditions in where/on clauses, excessive matching records for range scans

Index on Myanglog