MySQL 复杂查询优化

复杂查询概述

复杂查询是指涉及多个表连接、子查询、聚合函数、排序、分组和分页等操作的SQL语句。这类查询通常消耗大量的CPU、内存和IO资源，是数据库性能优化的重点和难点。

MySQL版本差异概述

优化领域	MySQL 5.6	MySQL 5.7	MySQL 8.0
查询优化器	基本优化规则，子查询优化有限	增强子查询优化，支持半连接优化	自适应哈希索引增强，直方图统计，CTE递归查询
执行计划	基本EXPLAIN输出	JSON格式执行计划，EXPLAIN ANALYZE	增强EXPLAIN ANALYZE，可视化执行计划
连接优化	支持内连接、外连接、交叉连接	增强连接算法，优化连接顺序	并行查询（部分支持），增强哈希连接
子查询	相关子查询效率低	物化子查询优化，半连接优化	增强CTE（公共表表达式），递归查询支持
聚合函数	基本聚合函数支持	增强GROUP BY优化，ROLLUP语法	窗口函数支持，增强聚合效率
分页查询	传统LIMIT offset, row_count	相同机制，性能随offset增大下降	相同机制，可使用CTE优化
索引支持	基本索引类型	虚拟列索引，前缀索引优化	函数索引，降序索引，不可见索引

复杂查询的特点

多表连接：涉及3个或更多表的连接操作
子查询嵌套：包含多层子查询，尤其是关联子查询
大量数据处理：需要处理百万级或千万级数据
复杂的过滤条件：包含多个AND/OR条件、范围查询等
聚合和排序：使用GROUP BY、ORDER BY、DISTINCT等操作
分页查询：涉及深分页（LIMIT offset, row_count）

复杂查询的优化目标

减少查询响应时间：将秒级查询优化到毫秒级
降低资源消耗：减少CPU、内存和IO的使用
提高并发处理能力：支持更多的并发查询
优化执行计划：引导MySQL优化器选择最优执行计划

复杂查询的优化思路

分析执行计划：使用EXPLAIN查看查询的执行计划
优化索引：为查询创建合适的索引
简化查询：拆复杂查询为多个简单查询
优化连接方式：选择合适的连接顺序和连接类型
优化子查询：使用JOIN替代子查询
优化聚合和排序：使用索引或临时表优化
优化分页查询：使用基于主键的分页替代LIMIT offset, row_count
考虑使用缓存：缓存查询结果
考虑使用物化视图：预计算复杂查询结果

多表连接查询优化

连接类型和执行顺序

连接类型：

INNER JOIN：内连接，只返回匹配的行
LEFT JOIN：左连接，返回左表所有行和右表匹配的行
RIGHT JOIN：右连接，返回右表所有行和左表匹配的行
OUTER JOIN：外连接，返回两个表的所有行

执行顺序：

MySQL优化器会自动选择连接顺序，优先连接结果集较小的表
可以使用STRAIGHT_JOIN强制连接顺序

连接查询优化技巧

1. 确保连接条件有索引

sql

-- 表结构
CREATE TABLE orders (
  id INT PRIMARY KEY,
  user_id INT,
  product_id INT,
  amount DECIMAL(10,2),
  INDEX idx_user_id (user_id),
  INDEX idx_product_id (product_id)
);

CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  INDEX idx_name (name)
);

CREATE TABLE products (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  INDEX idx_name (name)
);

-- 优化前：连接条件中的user_id和product_id都有索引
EXPLAIN SELECT o.id, u.name, p.name, o.amount 
FROM orders o 
JOIN users u ON o.user_id = u.id 
JOIN products p ON o.product_id = p.id;

2. 限制连接表的数量

sql

-- 不推荐：连接过多表（超过5个）
SELECT * FROM a 
JOIN b ON a.id = b.a_id 
JOIN c ON b.id = c.b_id 
JOIN d ON c.id = d.c_id 
JOIN e ON d.id = e.d_id 
JOIN f ON e.id = f.e_id 
WHERE a.status = 1;

-- 推荐：拆分为多个简单查询，或使用临时表
CREATE TEMPORARY TABLE temp_result AS 
SELECT a.id, b.id AS b_id, c.id AS c_id 
FROM a 
JOIN b ON a.id = b.a_id 
JOIN c ON b.id = c.b_id 
WHERE a.status = 1;

SELECT * FROM temp_result 
JOIN d ON temp_result.c_id = d.c_id 
JOIN e ON d.id = e.d_id 
JOIN f ON e.id = f.e_id;

3. 使用STRAIGHT_JOIN强制连接顺序

sql

-- 当优化器选择的连接顺序不是最优时，可以使用STRAIGHT_JOIN
EXPLAIN SELECT STRAIGHT_JOIN o.id, u.name, o.amount 
FROM orders o 
JOIN users u ON o.user_id = u.id 
WHERE u.name = 'test';

4. 避免在连接条件中使用函数

sql

-- 不推荐：在连接条件中使用函数
SELECT * FROM orders o 
JOIN users u ON DATE(o.create_time) = DATE(u.register_time);

-- 推荐：避免使用函数，或使用计算列
SELECT * FROM orders o 
JOIN users u ON o.create_time BETWEEN u.register_time AND DATE_ADD(u.register_time, INTERVAL 1 DAY);

连接查询优化案例

案例：

表结构：orders (1000万行), users (100万行), products (10万行)
查询：SELECT o.id, u.name, p.name, o.amount FROM orders o JOIN users u ON o.user_id = u.id JOIN products p ON o.product_id = p.id WHERE u.status = 1 AND p.category = 'electronics';
问题：查询执行时间超过10秒

优化步骤：

分析执行计划：使用EXPLAIN查看，发现全表扫描orders表
添加索引：为users表的status字段和products表的category字段添加索引
优化连接顺序：使用STRAIGHT_JOIN强制先连接users和products表，再连接orders表
使用覆盖索引：为orders表创建(user_id, product_id, id, amount)覆盖索引

优化后：

查询执行时间从10秒优化到0.1秒
使用了覆盖索引，避免了回表操作
连接顺序更合理，减少了中间结果集大小

子查询优化

子查询的类型

1. 标量子查询：返回单个值的子查询

sql

SELECT * FROM orders WHERE amount > (SELECT AVG(amount) FROM orders);

2. 行子查询：返回一行数据的子查询

sql

SELECT * FROM orders WHERE (user_id, product_id) = (SELECT user_id, product_id FROM orders WHERE id = 1);

3. 列子查询：返回一列数据的子查询

sql

SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount > 100);

4. 表子查询：返回多行多列数据的子查询

sql

SELECT * FROM users WHERE (id, name) IN (SELECT user_id, user_name FROM orders WHERE amount > 100);

5. 关联子查询：子查询中引用了外部表的列

sql

SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.amount > 100);

子查询优化技巧

1. 使用JOIN替代子查询

sql

-- 不推荐：使用子查询
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount > 100);

-- 推荐：使用JOIN
SELECT DISTINCT u.* FROM users u JOIN orders o ON u.id = o.user_id WHERE o.amount > 100;

2. 使用EXISTS替代IN

sql

-- 当子查询结果集较大时，使用EXISTS比IN更高效
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.amount > 100);

3. 避免关联子查询

sql

-- 不推荐：关联子查询，效率低
SELECT u.*, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_count FROM users u;

-- 推荐：使用JOIN和GROUP BY
SELECT u.*, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id;

4. 使用临时表优化复杂子查询

sql

-- 不推荐：复杂子查询嵌套
SELECT * FROM users WHERE id IN (
  SELECT user_id FROM orders WHERE product_id IN (
    SELECT id FROM products WHERE category = 'electronics'
  ) AND amount > 100
);

-- 推荐：使用临时表
CREATE TEMPORARY TABLE temp_products AS 
SELECT id FROM products WHERE category = 'electronics';

CREATE TEMPORARY TABLE temp_orders AS 
SELECT user_id FROM orders 
WHERE product_id IN (SELECT id FROM temp_products) AND amount > 100;

SELECT * FROM users WHERE id IN (SELECT user_id FROM temp_orders);

5. 优化标量子查询

sql

-- 优化前：标量子查询，每次外部查询都需要执行一次子查询
SELECT o.*, (SELECT name FROM products p WHERE p.id = o.product_id) AS product_name FROM orders o;

-- 推荐：使用JOIN
SELECT o.*, p.name AS product_name FROM orders o LEFT JOIN products p ON o.product_id = p.id;

子查询优化案例

案例：

表结构：orders (1000万行), users (100万行)
查询：SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount > 100 AND create_time > '2023-01-01');
问题：查询执行时间超过5秒

优化步骤：

分析执行计划：发现子查询被转换为相关子查询，效率低
使用JOIN替代IN子查询：SELECT DISTINCT u.* FROM users u JOIN orders o ON u.id = o.user_id WHERE o.amount > 100 AND o.create_time > '2023-01-01';
为orders表创建覆盖索引：CREATE INDEX idx_amount_create_time_user_id ON orders(amount, create_time, user_id);

优化后：

查询执行时间从5秒优化到0.05秒
使用了覆盖索引，避免了回表操作
JOIN方式比IN子查询更高效

聚合查询优化

聚合函数的类型

COUNT()：统计行数
SUM()：求和
AVG()：平均值
MAX()：最大值
MIN()：最小值
GROUP_CONCAT()：连接字符串

聚合查询优化技巧

1. 使用索引优化聚合函数

sql

-- 优化前：需要扫描全表
SELECT COUNT(*) FROM orders WHERE status = 1;

-- 推荐：为status字段创建索引
CREATE INDEX idx_status ON orders(status);
SELECT COUNT(*) FROM orders WHERE status = 1;

2. 优化GROUP BY查询

sql

-- 优化前：需要使用临时表和文件排序
SELECT user_id, SUM(amount) FROM orders GROUP BY user_id;

-- 推荐：为user_id字段创建索引
CREATE INDEX idx_user_id_amount ON orders(user_id, amount);
SELECT user_id, SUM(amount) FROM orders GROUP BY user_id;

3. 避免在GROUP BY中使用表达式

sql

-- 不推荐：在GROUP BY中使用函数
SELECT DATE(create_time), COUNT(*) FROM orders GROUP BY DATE(create_time);

-- 推荐：使用计算列或预先计算
CREATE TABLE orders (
  id INT PRIMARY KEY,
  create_time DATETIME,
  create_date DATE AS (DATE(create_time)) STORED,
  INDEX idx_create_date (create_date)
);

SELECT create_date, COUNT(*) FROM orders GROUP BY create_date;

4. 使用ROLLUP优化分组汇总

sql

-- 优化前：需要执行多次查询
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;
SELECT COUNT(*) FROM orders;

-- 推荐：使用ROLLUP
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id WITH ROLLUP;

5. 优化DISTINCT查询

sql

-- 优化前：需要使用临时表和文件排序
SELECT DISTINCT user_id FROM orders;

-- 推荐：为user_id字段创建索引
CREATE INDEX idx_user_id ON orders(user_id);
SELECT DISTINCT user_id FROM orders;

聚合查询优化案例

案例：

表结构：orders (1000万行)
查询：SELECT user_id, product_id, SUM(amount), COUNT(*) FROM orders WHERE create_time > '2023-01-01' GROUP BY user_id, product_id ORDER BY SUM(amount) DESC;
问题：查询执行时间超过8秒

优化步骤：

分析执行计划：发现使用了临时表和文件排序
创建覆盖索引：CREATE INDEX idx_create_time_user_id_product_id_amount ON orders(create_time, user_id, product_id, amount);
优化排序：利用覆盖索引的顺序，避免文件排序
限制结果集大小：添加LIMIT限制返回的行数

优化后：

查询执行时间从8秒优化到0.2秒
使用了覆盖索引，避免了回表操作
排序操作使用了索引，避免了文件排序
限制了结果集大小，减少了数据传输

排序和分组查询优化

排序查询优化

1. 使用索引优化ORDER BY

sql

-- 优化前：需要文件排序
SELECT * FROM orders ORDER BY create_time DESC;

-- 推荐：为create_time字段创建索引
CREATE INDEX idx_create_time ON orders(create_time);
SELECT * FROM orders ORDER BY create_time DESC;

2. 避免在ORDER BY中使用表达式

sql

-- 不推荐：在ORDER BY中使用函数
SELECT * FROM orders ORDER BY DATE(create_time) DESC;

-- 推荐：使用计算列
CREATE TABLE orders (
  id INT PRIMARY KEY,
  create_time DATETIME,
  create_date DATE AS (DATE(create_time)) STORED,
  INDEX idx_create_date (create_date)
);

SELECT * FROM orders ORDER BY create_date DESC;

3. 优化ORDER BY和LIMIT的组合

sql

-- 优化前：深分页查询，效率低
SELECT * FROM orders ORDER BY create_time DESC LIMIT 100000, 10;

-- 推荐：使用基于主键的分页
SELECT * FROM orders WHERE id > (SELECT id FROM orders ORDER BY create_time DESC LIMIT 100000, 1) ORDER BY create_time DESC LIMIT 10;

分组查询优化

1. 确保GROUP BY的字段有索引

sql

-- 优化前：需要使用临时表
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;

-- 推荐：为user_id字段创建索引
CREATE INDEX idx_user_id ON orders(user_id);
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;

2. 优化GROUP BY和ORDER BY的组合

sql

-- 优化前：需要使用临时表和文件排序
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY COUNT(*) DESC;

-- 推荐：使用覆盖索引和LIMIT
CREATE INDEX idx_user_id ON orders(user_id);
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY 2 DESC LIMIT 10;

3. 避免使用HAVING过滤大量数据

sql

-- 不推荐：使用HAVING过滤大量数据
SELECT user_id, SUM(amount) FROM orders GROUP BY user_id HAVING SUM(amount) > 1000;

-- 推荐：先过滤数据，再分组
SELECT user_id, SUM(amount) FROM orders WHERE amount > 100 GROUP BY user_id HAVING SUM(amount) > 1000;

排序和分组优化案例

案例：

表结构：orders (1000万行)
查询：SELECT user_id, SUM(amount) FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY user_id ORDER BY SUM(amount) DESC LIMIT 10;
问题：查询执行时间超过6秒

优化步骤：

分析执行计划：发现使用了临时表和文件排序
创建覆盖索引：CREATE INDEX idx_create_time_user_id_amount ON orders(create_time, user_id, amount);
优化HAVING条件：将过滤条件移到WHERE子句中
优化排序：利用覆盖索引的顺序，避免文件排序

优化后：

查询执行时间从6秒优化到0.1秒
使用了覆盖索引，避免了回表操作
排序操作使用了索引，避免了文件排序
先过滤数据，再分组，减少了分组的数据量

分页查询优化

分页查询的问题

sql

-- 传统分页查询，当offset很大时，效率很低
SELECT * FROM orders ORDER BY create_time DESC LIMIT 100000, 10;

问题分析：

MySQL需要扫描100010行数据，然后只返回10行
随着offset的增大，查询效率急剧下降
需要大量的IO和内存资源

分页查询优化技巧

1. 使用基于主键的分页

sql

-- 优化前：传统分页
SELECT * FROM orders ORDER BY create_time DESC LIMIT 100000, 10;

-- 推荐：基于主键的分页
SELECT o.* FROM orders o 
INNER JOIN (SELECT id FROM orders ORDER BY create_time DESC LIMIT 100000, 10) t ON o.id = t.id 
ORDER BY o.create_time DESC;

2. 使用seek方法分页

sql

-- 优化前：传统分页
SELECT * FROM orders ORDER BY create_time DESC LIMIT 100000, 10;

-- 推荐：seek方法，使用上一页的最后一条记录作为条件
SELECT * FROM orders WHERE create_time < '2023-05-01' ORDER BY create_time DESC LIMIT 10;

3. 优化COUNT(*)查询

sql

-- 优化前：需要扫描全表
SELECT COUNT(*) FROM orders;

-- 推荐：使用近似计数或缓存
-- 1. 使用SHOW TABLE STATUS获取近似行数
SHOW TABLE STATUS LIKE 'orders';

-- 2. 使用缓存存储准确计数
-- 3. 使用计数器表
CREATE TABLE orders_count (count INT);
UPDATE orders_count SET count = count + 1 WHERE id = 1;
SELECT count FROM orders_count WHERE id = 1;

4. 限制最大分页页数

sql

-- 不推荐：允许无限制的分页
SELECT * FROM orders ORDER BY create_time DESC LIMIT :offset, 10;

-- 推荐：限制最大offset
SELECT * FROM orders ORDER BY create_time DESC LIMIT LEAST(:offset, 1000000), 10;

分页查询优化案例

案例：

表结构：orders (1000万行)
查询：SELECT * FROM orders ORDER BY create_time DESC LIMIT 500000, 10;
问题：查询执行时间超过5秒

优化步骤：

分析执行计划：发现需要扫描500010行数据
使用基于主键的分页：先查询主键，再查询详细数据
使用覆盖索引：为create_time字段创建覆盖索引
考虑使用seek方法：如果前端支持，使用上一页的最后一条记录作为条件

优化后：

查询执行时间从5秒优化到0.05秒
只需要扫描10行数据，而不是500010行
使用了覆盖索引，避免了回表操作
分页查询的性能不再随offset的增大而下降

优化工具和技巧

使用EXPLAIN分析执行计划

sql

-- 查看基本执行计划
EXPLAIN SELECT * FROM orders WHERE status = 1;

-- 查看详细执行计划（JSON格式）
EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE status = 1;

-- 查看执行计划的警告信息
EXPLAIN WARNINGS SELECT * FROM orders WHERE status = 1;

使用PROFILE分析查询性能

sql

-- 启用 profiling
SET profiling = ON;

-- 执行查询
SELECT * FROM orders WHERE status = 1;

-- 查看查询 profile
SHOW PROFILES;
SHOW PROFILE FOR QUERY 1;

-- 查看详细的资源使用情况
SHOW PROFILE CPU, BLOCK IO FOR QUERY 1;

使用PERFORMANCE_SCHEMA分析查询

sql

-- 启用 performance_schema
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%statement%';
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE '%statement%';

-- 查看语句执行情况
SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY sum_timer_wait DESC LIMIT 10;

使用慢查询日志分析

ini

# 启用慢查询日志
slow_query_log = ON
slow_query_log_file = /var/lib/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = ON

分析工具：

mysqldumpslow：MySQL自带的慢查询分析工具
pt-query-digest：Percona Toolkit中的慢查询分析工具
MySQL Enterprise Monitor：商业监控工具

使用索引建议工具

1. 使用MySQL自带的索引建议

sql

-- 查看缺失的索引
SELECT * FROM sys.schema_table_statistics WHERE table_schema = 'test' ORDER BY rows_changed DESC LIMIT 10;

-- 查看未使用的索引
SELECT * FROM sys.schema_unused_indexes WHERE table_schema = 'test';

2. 使用第三方工具

pt-duplicate-key-checker：检测冗余索引
pt-index-usage：分析索引使用情况
MySQL Enterprise Monitor：提供索引建议

复杂查询优化案例分析

案例1：多表连接 + 子查询 + 聚合查询

问题描述：

表结构：orders (1000万行), users (100万行), products (10万行)
查询：

sql

SELECT u.name, p.name, COUNT(o.id), SUM(o.amount) 
FROM orders o 
JOIN users u ON o.user_id = u.id 
JOIN products p ON o.product_id = p.id 
WHERE u.status = 1 
AND p.category = 'electronics' 
AND o.create_time > '2023-01-01' 
AND o.amount > (SELECT AVG(amount) FROM orders WHERE product_id = p.id) 
GROUP BY u.name, p.name 
ORDER BY SUM(o.amount) DESC 
LIMIT 10;

问题：查询执行时间超过15秒

优化步骤：

分析执行计划：发现全表扫描orders表，子查询效率低
添加索引：
- 为users表的status字段创建索引
- 为products表的category字段创建索引
- 为orders表创建(create_time, user_id, product_id, amount)覆盖索引
优化子查询：将子查询转换为JOIN，或使用临时表预先计算
优化连接顺序：使用STRAIGHT_JOIN强制先连接users和products表
优化分组和排序：利用覆盖索引的顺序，避免文件排序

优化后：

查询执行时间从15秒优化到0.2秒
使用了覆盖索引，避免了回表操作
子查询被优化为JOIN，提高了效率
连接顺序更合理，减少了中间结果集大小
分组和排序使用了索引，避免了临时表和文件排序

案例2：深分页查询

问题描述：

表结构：logs (1亿行)
查询：SELECT * FROM logs ORDER BY create_time DESC LIMIT 1000000, 10;
问题：查询执行时间超过20秒

优化步骤：

分析执行计划：发现需要扫描1000010行数据
使用基于主键的分页：先查询主键，再查询详细数据
使用覆盖索引：为create_time字段创建覆盖索引
考虑使用分区表：按时间分区，减少扫描的数据量
使用seek方法：如果前端支持，使用上一页的最后一条记录作为条件

优化后：

查询执行时间从20秒优化到0.1秒
只需要扫描10行数据，而不是1000010行
使用了覆盖索引，避免了回表操作
考虑使用分区表，进一步提高性能

复杂查询优化最佳实践

设计阶段优化

合理设计表结构：
- 选择合适的数据类型
- 避免过度规范化
- 考虑使用分区表
合理设计索引：
- 为常用的查询条件创建索引
- 考虑覆盖索引
- 避免冗余索引
避免复杂查询：
- 将复杂查询拆分为多个简单查询
- 考虑使用缓存
- 考虑使用物化视图

开发阶段优化

编写高效的SQL：
- 避免SELECT *
- 使用JOIN替代子查询
- 避免在WHERE子句中使用函数
- 限制结果集大小
分析执行计划：
- 使用EXPLAIN分析每个复杂查询
- 关注type、key、rows和Extra字段
- 优化执行计划中出现的问题
测试和验证：
- 在测试环境中测试查询性能
- 使用真实数据量进行测试
- 验证优化效果

运维阶段优化

监控和分析：
- 监控慢查询日志
- 分析查询性能趋势
- 识别性能瓶颈
优化和调整：
- 定期优化表和索引
- 调整MySQL参数
- 考虑升级硬件
持续优化：
- 定期审查和优化复杂查询
- 关注业务变化，调整优化策略
- 学习和应用新的优化技术

总结

复杂查询优化是MySQL性能优化的重要组成部分，需要综合考虑查询设计、索引优化、表结构设计和MySQL配置等多个方面。

在优化复杂查询时，DBA需要：

分析执行计划：使用EXPLAIN查看查询的执行计划
优化索引：为查询创建合适的索引
简化查询：拆复杂查询为多个简单查询
优化连接和子查询：选择合适的连接方式和子查询类型
优化聚合和排序：使用索引或临时表优化
优化分页查询：使用基于主键的分页或seek方法
使用工具辅助：使用慢查询日志、PROFILE和PERFORMANCE_SCHEMA等工具

通过持续的优化和调整，可以显著提高复杂查询的性能，降低数据库负载，提高系统的可用性和可扩展性。

MySQL 复杂查询优化 ​

复杂查询概述 ​

MySQL版本差异概述 ​

复杂查询的特点 ​

复杂查询的优化目标 ​

复杂查询的优化思路 ​

多表连接查询优化 ​

连接类型和执行顺序 ​

连接查询优化技巧 ​

连接查询优化案例 ​

子查询优化 ​

子查询的类型 ​

子查询优化技巧 ​

子查询优化案例 ​

聚合查询优化 ​

聚合函数的类型 ​

聚合查询优化技巧 ​

聚合查询优化案例 ​

排序和分组查询优化 ​

排序查询优化 ​

分组查询优化 ​

排序和分组优化案例 ​

分页查询优化 ​

分页查询的问题 ​

分页查询优化技巧 ​

分页查询优化案例 ​

优化工具和技巧 ​

使用EXPLAIN分析执行计划 ​

使用PROFILE分析查询性能 ​

使用PERFORMANCE_SCHEMA分析查询 ​

使用慢查询日志分析 ​

使用索引建议工具 ​

复杂查询优化案例分析 ​

案例1：多表连接 + 子查询 + 聚合查询 ​

案例2：深分页查询 ​

复杂查询优化最佳实践 ​

设计阶段优化 ​

开发阶段优化 ​

运维阶段优化 ​

总结 ​

MySQL 复杂查询优化

复杂查询概述

MySQL版本差异概述

复杂查询的特点

复杂查询的优化目标

复杂查询的优化思路

多表连接查询优化

连接类型和执行顺序

连接查询优化技巧

连接查询优化案例

子查询优化

子查询的类型

子查询优化技巧

子查询优化案例

聚合查询优化

聚合函数的类型

聚合查询优化技巧

聚合查询优化案例

排序和分组查询优化

排序查询优化

分组查询优化

排序和分组优化案例

分页查询优化

分页查询的问题

分页查询优化技巧

分页查询优化案例

优化工具和技巧

使用EXPLAIN分析执行计划

使用PROFILE分析查询性能

使用PERFORMANCE_SCHEMA分析查询

使用慢查询日志分析

使用索引建议工具

复杂查询优化案例分析

案例1：多表连接 + 子查询 + 聚合查询

案例2：深分页查询

复杂查询优化最佳实践

设计阶段优化

开发阶段优化

运维阶段优化

总结