## 1. 案例背景
– 表：fgedu_orders（订单表）
– 数据量：1000万行
– 查询：SELECT * FROM fgedu_orders WHERE user_id = 1 AND status = ‘completed’;

## 2. 分析过程

### 步骤1：查看执行计划
mysql> EXPLAIN SELECT * FROM fgedu_orders WHERE user_id = 1 AND status = ‘completed’;

### 步骤2：分析执行计划输出
– id: 1
– select_type: SIMPLE
– table: fgedu_orders
– type: ALL
– possible_keys: NULL
– key: NULL
– key_len: NULL
– ref: NULL
– rows: 10000000
– filtered: 10.00
– Extra: Using where

### 步骤3：识别问题
– 访问类型为ALL（全表扫描）
– 未使用索引
– 估计扫描1000万行

### 步骤4：优化方案
– 创建复合索引：(user_id, status)

### 步骤5：实施优化
mysql> ALTER TABLE fgedu_orders ADD INDEX idx_user_id_status (user_id, status);

### 步骤6：验证优化效果
mysql> EXPLAIN SELECT * FROM fgedu_orders WHERE user_id = 1 AND status = ‘completed’;

### 步骤7：分析优化后的执行计划
– id: 1
– select_type: SIMPLE
– table: fgedu_orders
– type: ref
– possible_keys: idx_user_id_status
– key: idx_user_id_status
– key_len: 82
– ref: const,const
– rows: 100
– filtered: 100.00
– Extra: NULL

## 3. 优化效果
– 访问类型从ALL变为ref
– 使用了复合索引idx_user_id_status
– 估计扫描行数从1000万行减少到100行
– 查询性能显著提升

## 1. 案例背景
– 表：fgedu_users（用户表）和fgedu_orders（订单表）
– 数据量：fgedu_users 100万行，fgedu_orders 1000万行
– 查询：SELECT u.name, o.order_no, o.amount FROM fgedu_users u JOIN fgedu_orders o ON u.id = o.user_id WHERE u.status = ‘active’ AND o.created_at > ‘2024-01-01’;

## 2. 分析过程

### 步骤1：查看执行计划
mysql> EXPLAIN SELECT u.name, o.order_no, o.amount FROM fgedu_users u JOIN fgedu_orders o ON u.id = o.user_id WHERE u.status = ‘active’ AND o.created_at > ‘2024-01-01’;

### 步骤2：分析执行计划输出
– id: 1
– select_type: SIMPLE
– table: u
– type: ALL
– possible_keys: PRIMARY
– key: NULL
– key_len: NULL
– ref: NULL
– rows: 1000000
– filtered: 10.00
– Extra: Using where

– id: 1
– select_type: SIMPLE
– table: o
– type: ref
– possible_keys: idx_user_id
– key: idx_user_id
– key_len: 4
– ref: fgedudb.u.id
– rows: 10
– filtered: 50.00
– Extra: Using where

### 步骤3：识别问题
– fgedu_users表使用全表扫描
– 未使用status索引
– 连接操作效率低

### 步骤4：优化方案
– 在fgedu_users表上创建status索引
– 在fgedu_orders表上创建(user_id, created_at)复合索引
– 调整查询语句，确保使用索引

### 步骤5：实施优化
mysql> ALTER TABLE fgedu_users ADD INDEX idx_status (status);
mysql> ALTER TABLE fgedu_orders ADD INDEX idx_user_id_created_at (user_id, created_at);

### 步骤6：验证优化效果
mysql> EXPLAIN SELECT u.name, o.order_no, o.amount FROM fgedu_users u JOIN fgedu_orders o ON u.id = o.user_id WHERE u.status = ‘active’ AND o.created_at > ‘2024-01-01’;

### 步骤7：分析优化后的执行计划
– id: 1
– select_type: SIMPLE
– table: u
– type: ref
– possible_keys: PRIMARY,idx_status
– key: idx_status
– key_len: 82
– ref: const
– rows: 100000
– filtered: 100.00
– Extra: NULL

– id: 1
– select_type: SIMPLE
– table: o
– type: ref
– possible_keys: idx_user_id,idx_user_id_created_at
– key: idx_user_id_created_at
– key_len: 12
– ref: fgedudb.u.id
– rows: 5
– filtered: 100.00
– Extra: Using where; Using index

## 3. 优化效果
– fgedu_users表使用ref访问类型，使用idx_status索引
– fgedu_orders表使用ref访问类型，使用idx_user_id_created_at索引
– 估计扫描行数显著减少
– 查询性能显著提升

## 1. 测试环境
– 数据库：TiDB 7.5.0
– 服务器：8核16GB
– 表：fgedu_orders（1000万行）

## 2. 测试场景
– 未优化的查询
– 优化后的查询

## 3. 性能测试

### 场景1：简单查询
– 未优化：SELECT * FROM fgedu_orders WHERE user_id = 1 AND status = ‘completed’;
– 响应时间：1.5秒
– 扫描行数：1000万行
– 执行计划：全表扫描

– 优化后：创建复合索引 (user_id, status)
– 响应时间：0.05秒
– 扫描行数：100行
– 执行计划：索引扫描

### 场景2：连接查询
– 未优化：SELECT u.name, o.order_no FROM fgedu_users u JOIN fgedu_orders o ON u.id = o.user_id WHERE u.status = ‘active’;
– 响应时间：2.0秒
– 扫描行数：1000万行
– 执行计划：全表扫描

– 优化后：创建索引 idx_status (status) 和 idx_user_id (user_id)
– 响应时间：0.1秒
– 扫描行数：10万行
– 执行计划：索引扫描

### 场景3：排序查询
– 未优化：SELECT * FROM fgedu_orders WHERE status = ‘completed’ ORDER BY created_at DESC;
– 响应时间：1.8秒
– 扫描行数：1000万行
– 执行计划：全表扫描 + 文件排序

– 优化后：创建复合索引 (status, created_at)
– 响应时间：0.15秒
– 扫描行数：100万行
– 执行计划：索引扫描 + 索引排序

## 4. 调优建议
– 为频繁查询的列创建索引
– 合理设计复合索引的列顺序
– 利用覆盖索引减少回表操作
– 优化SQL语句，确保使用索引
– 定期分析执行计划，及时调整优化策略