## 1. 案例背景
– 系统：TiDB 7.5.0
– 表：fgedu_orders（订单表）
– 数据量：1亿行
– 问题：查询性能差，写入速度慢

## 2. 分析过程
– 检查分区策略：使用Range分区按年分区，分区过大
– 检查查询语句：未充分利用分区裁剪
– 检查系统参数：默认参数配置

## 3. 优化方案
– 调整分区策略：从按年分区改为按月分区
– 优化查询语句：确保查询条件包含分区键
– 调整系统参数：优化TiDB和TiKV参数
– 建立监控体系：设置性能监控和告警

## 4. 实施步骤

### 步骤1：修改分区策略
mysql> ALTER TABLE fgedu_orders REORGANIZE PARTITION p2024 INTO (
-> PARTITION p202401 VALUES LESS THAN (TO_DAYS(‘2024-02-01’)),
-> PARTITION p202402 VALUES LESS THAN (TO_DAYS(‘2024-03-01’)),
-> PARTITION p202403 VALUES LESS THAN (TO_DAYS(‘2024-04-01’)),
-> PARTITION p202404 VALUES LESS THAN (TO_DAYS(‘2024-05-01’)),
-> PARTITION p202405 VALUES LESS THAN (TO_DAYS(‘2024-06-01’)),
-> PARTITION p202406 VALUES LESS THAN (TO_DAYS(‘2024-07-01’)),
-> PARTITION p202407 VALUES LESS THAN (TO_DAYS(‘2024-08-01’)),
-> PARTITION p202408 VALUES LESS THAN (TO_DAYS(‘2024-09-01’)),
-> PARTITION p202409 VALUES LESS THAN (TO_DAYS(‘2024-10-01’)),
-> PARTITION p202410 VALUES LESS THAN (TO_DAYS(‘2024-11-01’)),
-> PARTITION p202411 VALUES LESS THAN (TO_DAYS(‘2024-12-01’)),
-> PARTITION p202412 VALUES LESS THAN (TO_DAYS(‘2025-01-01’))
-> );

### 步骤2：优化查询语句
– 原查询：SELECT * FROM fgedu_orders WHERE DATE(created_at) = ‘2024-01-01’;
– 优化后：SELECT * FROM fgedu_orders WHERE created_at BETWEEN ‘2024-01-01 00:00:00’ AND ‘2024-01-01 23:59:59’;

### 步骤3：调整系统参数
– 修改tidb.toml：
tidb_max_chunk_size = 134217728
tidb_distsql_scan_concurrency = 30

– 修改tikv.toml：
raftstore.apply-pool-size = 4
raftstore.store-pool-size = 4
rocksdb.max-open-files = 8192

### 步骤4：建立监控
– 配置Prometheus和Grafana
– 设置分区大小和查询性能告警

## 5. 优化效果
– 查询响应时间：从2.5秒降低到0.3秒
– 写入速度：从500行/秒提升到2000行/秒
– 分区裁剪率：从30%提升到95%
– 系统稳定性：显著提高

## 1. 案例背景
– 表：fgedu_user_logs（用户日志表）
– 分区策略：Hash分区按user_id分区，8个分区
– 问题：点查询性能差

## 2. 分析过程
– 检查查询语句：SELECT * FROM fgedu_user_logs WHERE user_id = 12345;
– 查看执行计划：使用全表扫描，未使用分区裁剪
– 检查分区键：user_id是分区键

## 3. 优化方案
– 检查分区键类型：确保查询条件类型与分区键类型一致
– 优化索引：在user_id上创建索引
– 调整分区数量：增加分区数量提高并行度

## 4. 实施步骤

### 步骤1：检查分区键类型
mysql> SHOW CREATE TABLE fgedu_user_logs;

### 步骤2：优化索引
mysql> ALTER TABLE fgedu_user_logs ADD INDEX idx_user_id (user_id);

### 步骤3：调整分区数量
mysql> ALTER TABLE fgedu_user_logs PARTITION BY HASH (user_id) PARTITIONS 16;

### 步骤4：测试查询性能
mysql> EXPLAIN SELECT * FROM fgedu_user_logs WHERE user_id = 12345;
mysql> SELECT * FROM fgedu_user_logs WHERE user_id = 12345;

## 5. 优化效果
– 查询响应时间：从0.8秒降低到0.1秒
– 扫描行数：从100万行减少到1000行
– 分区裁剪：成功使用分区裁剪

## 1. 案例背景
– 表：fgedu_orders（订单表）
– 分区策略：Range分区按月分区
– 问题：分区维护成本高，性能下降

## 2. 分析过程
– 检查分区状态：部分分区数据量过大
– 检查维护历史：未定期维护
– 检查统计信息：统计信息过期

## 3. 优化方案
– 自动化分区维护：编写维护脚本
– 定期重建分区：保持分区性能
– 定期分析统计信息：优化执行计划
– 归档历史数据：减少分区大小

## 4. 实施步骤

### 步骤1：编写维护脚本
“`bash
#!/bin/bash
# partition_maintenance.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`

# 定期分析分区统计信息
mysql -u root -p -e “ALTER TABLE fgedu_orders ANALYZE PARTITION ALL;”

# 定期重建分区
mysql -u root -p -e “ALTER TABLE fgedu_orders REBUILD PARTITION ALL;”

# 定期添加新分区
next_month=$(date -d “+1 month” +%Y%m)
next_month_first=$(date -d “${next_month}01” +%Y-%m-%d)
mysql -u root -p -e “ALTER TABLE fgedu_orders ADD PARTITION (PARTITION p${next_month} VALUES LESS THAN (TO_DAYS(‘${next_month_first}’)));”

# 定期删除旧分区
old_month=$(date -d “-12 month” +%Y%m)
mysql -u root -p -e “ALTER TABLE fgedu_orders DROP PARTITION p${old_month};”
“`

### 步骤2：设置定时任务
“`bash
# 添加到crontab
0 1 * * * /path/to/partition_maintenance.sh
“`

### 步骤3：归档历史数据
– 创建归档表：CREATE TABLE fgedu_orders_archive LIKE fgedu_orders;
– 归档数据：INSERT INTO fgedu_orders_archive SELECT * FROM fgedu_orders WHERE created_at < '2023-01-01'; - 删除旧数据：ALTER TABLE fgedu_orders DROP PARTITION p202301, p202302, ..., p202312; ## 5. 优化效果 - 维护成本：从手动维护改为自动维护 - 分区性能：保持稳定，避免性能下降 - 存储空间：减少30%的存储空间 - 查询性能：保持稳定，避免统计信息过期导致的性能问题