本文档风哥主要介绍TiDB CPU高负载优化处理，包括CPU高负载的概念、CPU高负载的原因、CPU高负载的影响、CPU监控规划、CPU优化策略、CPU监控工具配置、CPU瓶颈分析方法等内容，风哥教程参考TiDB官方文档性能优化相关内容编写，适合DBA人员在学习和测试中使用，如果要应用于生产环境则需要自行确认。更多视频教程www.fgedu.net.cn
Part01-基础概念与理论知识
1.1 CPU高负载的概念
CPU高负载是指CPU使用率持续处于较高水平，导致系统性能下降的现象。CPU高负载的判断标准：学习交流加群风哥微信: itpux-com
- CPU使用率：持续超过80%
- 负载平均值：超过CPU核心数
- 系统响应：系统响应缓慢，SQL执行时间长
- 进程状态：大量进程处于运行状态
1.2 CPU高负载的原因
TiDB CPU高负载的常见原因：
## 1. SQL相关原因
– 复杂查询：执行计划复杂，需要大量CPU计算
– 全表扫描：缺少索引，导致全表扫描
– 高并发查询：并发度高，CPU资源竞争
– 慢SQL：执行时间长的SQL语句
– 大量小查询：频繁的小查询累积导致CPU负载高
## 2. 系统相关原因
– 系统资源不足：CPU核心数不足
– 内存不足：内存不足导致频繁的磁盘IO，间接增加CPU负载
– 磁盘IO瓶颈：IO操作缓慢，CPU等待IO完成
– 网络瓶颈：网络传输缓慢，CPU等待网络数据
– 其他进程占用：系统中其他进程占用大量CPU资源
## 3. TiDB配置相关原因
– 配置参数不合理：如并发度设置过高
– 垃圾回收：TiDB的垃圾回收过程占用CPU
– 统计信息更新：统计信息更新过程占用CPU
– 后台任务：如备份、压缩等后台任务
## 4. 业务相关原因
– 业务高峰期：业务量突然增加
– 批量操作：大量的批量插入、更新或删除操作
– 数据迁移：数据迁移过程占用CPU
– 索引重建：重建索引过程占用CPU
1.3 CPU高负载的影响
CPU高负载的影响：
- 系统响应缓慢：SQL执行时间延长，用户体验下降
- 吞吐量下降：系统处理的请求数量减少
- 服务不可用：严重的CPU高负载可能导致服务崩溃
- 其他资源竞争：CPU高负载可能导致内存、IO等其他资源的竞争
- 系统不稳定：长期的CPU高负载会导致系统不稳定，容易出现故障
风哥提示：
Part02-生产环境规划与建议
2.1 CPU监控规划
CPU监控规划要点：
## 1. 监控目标
– 实时监控CPU使用率
– 及时发现CPU高负载情况
– 分析CPU使用趋势
– 为CPU优化提供依据
## 2. 监控指标
– CPU使用率：整体和每个核心的使用率
– 负载平均值：1分钟、5分钟、15分钟负载
– 进程CPU使用率：各个进程的CPU使用情况
– 上下文切换：上下文切换次数
– 运行队列长度：等待CPU的进程数量
## 3. 监控工具
– TiDB Dashboard：查看TiDB进程的CPU使用情况
– Prometheus：存储和查询CPU相关指标
– Grafana：展示CPU监控面板
– top/htop：实时查看系统CPU使用情况
– sar：收集系统CPU使用统计信息
## 4. 监控频率
– 实时监控：1-5秒
– 定期监控：1-5分钟
– 离线分析：每日或每周
## 5. 告警配置
– 告警阈值：CPU使用率超过80%持续5分钟
– 告警级别：紧急、重要、警告
– 告警渠道：邮件、短信、微信
– 告警策略：避免告警风暴
2.2 CPU优化策略
CPU优化策略：
## 1. SQL优化
– 优化查询语句：简化查询逻辑，减少CPU计算
– 添加索引：避免全表扫描，减少CPU开销
– 优化执行计划：使用合适的执行计划
– 减少查询数据量：只查询需要的字段
– 批量处理：减少小查询的数量
## 2. 系统优化
– 增加CPU资源：添加CPU核心或升级CPU
– 优化系统配置：调整系统参数，如调度策略
– 关闭不必要的服务：减少系统负载
– 合理分配资源：使用cgroups等工具分配CPU资源
## 3. TiDB配置优化
– 调整并发度：根据CPU核心数调整并发度
– 优化垃圾回收：调整垃圾回收参数
– 优化统计信息更新：调整统计信息更新策略
– 合理设置参数：如tidb_analyze_version、tidb_enable_fast_plan
## 4. 业务优化
– 错峰处理：避开业务高峰期进行批量操作
– 限流：对高并发请求进行限流
– 缓存：使用缓存减少数据库访问
– 异步处理：将耗时操作改为异步处理
## 5. 架构优化
– 读写分离：将读请求分散到多个TiDB实例
– 水平扩展：增加TiDB实例数量
– 分片：将数据分散到多个TiKV节点
– 负载均衡：使用负载均衡分散请求
2.3 CPU容量规划
CPU容量规划：
## 1. 容量评估
– 业务峰值QPS：评估业务高峰期的QPS
– 单查询CPU消耗：测量单个查询的CPU消耗
– 并发度：评估系统的并发处理能力
– 未来增长：考虑业务增长对CPU的需求
## 2. 容量计算
– 所需CPU核心数 = 峰值QPS × 单查询CPU消耗 × 安全系数学习交流加群风哥QQ113257174
– 安全系数：一般为1.5-2.0
## 3. 容量扩展
– 垂直扩展：增加CPU核心数或升级CPU
– 水平扩展：增加TiDB实例数量
– 混合扩展：同时进行垂直和水平扩展
## 4. 容量监控
– 定期监控CPU使用率
– 分析CPU使用趋势
– 预测未来CPU需求
– 及时进行容量扩展
## 5. 容量优化
– 优化SQL和业务逻辑，减少CPU消耗
– 合理配置TiDB参数，提高CPU利用率
– 使用缓存和读写分离，减少CPU负载
Part03-生产环境项目实施方案
3.1 CPU监控工具配置
3.1.1 TiDB Dashboard CPU监控
## 1. 访问TiDB Dashboard
http://192.168.1.10:2379/dashboard
## 2. 查看CPU使用率
– 点击左侧菜单”实例” -> “TiDB”
– 查看每个TiDB实例的CPU使用率
– 查看CPU使用率的历史趋势
## 3. 查看慢SQL
– 点击左侧菜单”SQL语句” -> “慢查询”
– 分析消耗CPU较多的SQL语句
– 查看SQL执行计划
## 4. 查看进程列表
– 点击左侧菜单”实例” -> “TiDB” -> “进程列表”
– 查看每个进程的CPU使用率
– 识别占用CPU较多的进程
3.1.2 Prometheus和Grafana CPU监控
## 1. 配置Prometheus收集CPU指标
$ vim prometheus.yml
global:
scrape_interval: 15s
scrape_configs:
– job_name: ‘tidb’
static_configs:
– targets: [‘192.168.1.10:10080’]
– job_name: ‘node’
static_configs:
– targets: [‘192.168.1.10:9100’, ‘192.168.1.20:9100’, ‘192.168.1.30:9100’]
## 2. 安装Node Exporter
$ wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
$ tar -xzf node_exporter-1.3.1.linux-amd64.tar.gz
$ cd node_exporter-1.3.1.linux-amd64
$ ./node_exporter
## 3. 配置Grafana面板
– 登录Grafana：http://192.168.1.10:3000
– 添加Prometheus数据源
– 导入CPU监控面板
– 配置CPU使用率告警
## 4. 查看CPU监控面板
– 查看整体CPU使用率
– 查看每个核心的CPU使用率
– 查看CPU负载平均值
– 查看CPU使用趋势
3.2 CPU瓶颈分析方法
3.2.1 CPU瓶颈分析步骤
## 1. 收集CPU使用数据
– 使用top命令查看CPU使用率：top
– 使用mpstat查看每个核心的CPU使用率：mpstat -P ALL 1
– 使用pidstat查看进程的CPU使用率：pidstat -u 1
– 使用Prometheus查询历史CPU数据
## 2. 识别CPU密集型进程
– 查看占用CPU最多的进程：top -o %CPU
– 查看TiDB相关进程的CPU使用率：pidstat -u -p $(pgrep -f tidb-server)
– 分析进程的CPU使用模式：是用户空间还是系统空间
## 3. 分析SQL语句
– 查看慢SQL日志：tail -f /tidb/app/tidb/log/tidb-slow.log
– 分析消耗CPU较多的SQL语句：使用EXPLAIN查看执行计划
– 识别全表扫描和复杂查询
## 4. 分析系统资源
– 查看内存使用情况：free -h
– 查看磁盘IO情况：iostat -x 1
– 查看网络情况：iftop -i eth0
– 分析是否存在其他资源瓶颈
## 5. 定位根因
– 确定CPU高负载的根本原因
– 分析是SQL问题、系统问题还是配置问题
– 评估影响范围和严重程度
3.2.2 常用分析工具
## 1. top/htop
– 功能：实时查看系统和进程的CPU使用情况
– 适用场景：实时监控CPU使用情况
– 优势：简单易用，实时性强
## 2. mpstat
– 功能：查看每个CPU核心的使用情况
– 适用场景：分析CPU核心的负载分布
– 优势：可以查看每个核心的详细使用情况
## 3. pidstat
– 功能：查看进程的CPU使用情况
– 适用场景：分析特定进程的CPU使用情况
– 优势：可以查看每个进程的详细CPU使用情况
## 4. sar
– 功能：收集和报告系统CPU使用统计信息
– 适用场景：分析CPU使用趋势
– 优势：可以查看历史CPU使用情况
## 5. TiDB Dashboard
– 功能：查看TiDB进程的CPU使用情况和慢SQL
– 适用场景：分析TiDB相关的CPU使用情况
– 优势：集成在TiDB中，使用方便
## 6. Prometheus和Grafana
– 功能：存储和可视化CPU相关指标
– 适用场景：分析CPU使用趋势和历史数据
– 优势：强大的查询和可视化能力
3.3 CPU优化实施方案
3.3.1 SQL优化实施
## 1. 分析慢SQL
– 查看慢SQL日志：tail -f /tidb/app/tidb/log/tidb-slow.log
– 分析SQL执行计划：EXPLAIN SELECT * FROM fgedu_users WHERE name LIKE ‘%test%’;
– 识别性能瓶颈：如全表扫描、复杂JOIN等
## 2. 添加索引
– 根据查询条件添加索引：ALTER TABLE fgedu_users ADD INDEX idx_name (name);
– 优化复合索引：合理设计复合索引的顺序
– 验证索引效果：EXPLAIN SELECT * FROM fgedu_users WHERE name = ‘test’;
## 3. 优化SQL语句
– 减少查询字段：只查询需要的字段
– 避免使用SELECT *：减少数据传输和CPU计算
– 优化JOIN操作：使用合适的JOIN类型
– 避免子查询：尽量使用JOIN替代子查询
– 合理使用分页：使用LIMIT进行分页
## 4. 验证优化效果
– 执行优化后的SQL语句
– 查看执行时间：SET profiling = 1; SELECT * FROM fgedu_users WHERE name = ‘test’; SHOW PROFILES;
– 查看CPU使用率：top
3.3.2 系统优化实施
## 1. 调整系统参数
– 调整调度策略：echo “deadline” > /sys/block/sda/queue/scheduler
– 调整内存参数：echo 1 > /proc/sys/vm/overcommit_memory
– 调整网络参数：echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
## 2. 优化TiDB配置
$ vim /tidb/app/tidb/conf/tidb.toml
[performance]
# 调整并发度
max-procs = 8
# 优化垃圾回收
gc-ratio = 1.0
# 优化统计信息更新
tidb_analyze_version = 2
## 3. 增加CPU资源
– 添加CPU核心：升级服务器或添加CPU
– 水平扩展：增加TiDB实例数量
– 负载均衡：使用负载均衡分散请求
## 4. 验证优化效果
– 查看CPU使用率：top
– 查看系统响应时间：ping 192.168.1.10
– 查看SQL执行时间：SET profiling = 1; SELECT * FROM fgedu_users WHERE name = ‘test’; SHOW PROFILES;
Part04-生产案例与实战讲解
4.1 CPU高负载检测与分析
4.1.1 CPU高负载检测
## 1. 实时监控CPU使用率
$ top
# 输出示例
top – 10:00:00 up 1 day, 2:00, 2 users, load average: 8.50, 7.20, 6.80
Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie
%Cpu(s): 90.0 us, 5.0 sy, 0.0 ni, 5.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12345 tidb 20 0 8.0g 2.0g 100m S 95.0 25.0 1:30.00 tidb-server
## 2. 查看每个核心的CPU使用率
$ mpstat -P ALL 1
# 输出示例
Linux 5.4.0-100-generic (fgedu.net.cn) 04/09/2026 _x86_64_ (8 CPU)
10:00:00 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
10:00:01 all 85.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 10.00
10:00:01 0 90.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 5.00
10:00:01 1 85.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 10.00
10:00:01 2 80.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 15.00
10:00:01 3 95.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:00:01 4 85.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 10.00
10:00:01 5 80.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 15.00
10:00:01 6 90.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 5.00
10:00:01 7 85.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 10.00
## 3. 查看TiDB进程的CPU使用率
$ pidstat -u -p $(pgrep -f tidb-server)
# 输出示例
Linux 5.4.0-100-generic (fgedu.net.cn) 04/09/2026 _x86_64_ (8 CPU)
10:00:00 UID PID %usr %system %guest %CPU CPU Command
10:00:01 1000 12345 90.00 5.00 0.00 95.00 3 tidb-server
## 4. 查看慢SQL日志
$ tail -f /tidb/app/tidb/log/tidb-slow.log
# 输出示例
[2026/04/09 10:00:00.000 +08:00] [SLOW] [session.go:1137] [“slow query”] [conn=12345] [user=fgedu] [db=fgedudb] [table_ids=”[1000]”] [start_time=”2026-04-09 10:00:00.000″] [elapsed=10.000s] [sql=”SELECT * FROM fgedu_users WHERE name LIKE ‘%test%'”] [digest=”abcdef123456″]
4.1.2 CPU高负载分析
## 1. 分析SQL执行计划
mysql> EXPLAIN SELECT * FROM fgedu_users WHERE name LIKE ‘%test%’;
# 输出示例
+————————-+———-+———–+—————+——————————–+————————-+———+——+————————–+———————–+
| id | estRows | task | access object | operator info | actRows | execution info | memory | disk | transaction info | operator info |
+————————-+———-+———–+—————+——————————–+————————-+———+——+————————–+———————–+
| TableReader_6 | 1000.00 | root | | data:TableScan_5 | 1000 | time:0.1s | 1.00 KB | N/A | | N/A |
| └─TableScan_5 | 1000.00 | cop[tikv] | table:fgedu_users | range:[-inf,+inf], keep order:false | 1000 | time:0.1s | N/A | N/A | | N/A |
+————————-+———-+———–+—————+——————————–+————————-+———+——+————————–+———————–+
## 2. 分析系统资源使用情况
$ free -h
# 输出示例
total used free shared buff/cache available
Mem: 32G 16G 14G 1.0G 2.0G 14G
Swap: 8.0G 0.0G 8.0G
$ iostat -x 1
# 输出示例
Linux 5.4.0-100-generic (fgedu.net.cn) 04/09/2026 _x86_64_ (8 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
85.00 0.00 5.00 0.00 0.00 10.00
device r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 10.00 20.00 819.20 1638.40 163.84 0.10 3.33 1.00 4.00 0.33 0.99
## 3. 分析网络情况
$ iftop -i eth0
# 输出示例
interface: eth0
IP address is: 192.168.1.10
MAC address is: 00:11:22:33:44:55
192.168.1.100 => 192.168.1.10 100Mb 80Mb 60Mb
192.168.1.10 => 192.168.1.100 80Mb 60Mb 40Mb
## 4. 定位根因
– 根因：SQL语句执行全表扫描，导致CPU使用率高
– 影响：系统响应缓慢，其他查询受到影响
– 解决方案：为name字段添加索引
4.2 CPU优化实战
4.2.1 SQL优化实战
## 1. 问题：全表扫描导致CPU高负载
– SQL语句：SELECT * FROM fgedu_users WHERE name LIKE ‘%test%’;
– 执行计划：全表扫描
– CPU使用率：95%
## 2. 解决方案：添加索引
– 添加索引：ALTER TABLE fgedu_users ADD INDEX idx_name (name);
– 验证索引：SHOW INDEX FROM fgedu_users;
## 3. 优化后的执行计划
mysql> EXPLAIN SELECT * FROM fgedu_users WHERE name LIKE ‘test%’;
# 输出示例
+————————-+———-+———–+—————+——————————–+————————-+———+——+————————–+———————–+
| id | estRows | task | access object | operator info | actRows | execution info | memory | disk | transaction info | operator info |
+————————-+———-+———–+—————+——————————–+————————-+———+——+————————–+———————–+
| IndexReader_6 | 10.00 | root | | index:IndexRangeScan_5 | 10 | time:0.01s | 1.00 KB | N/A | | N/A |
| └─IndexRangeScan_5 | 10.00 | cop[tikv] | table:fgedu_users, index:idx_name(name) | range:[“test”,”test”), keep order:false | 10 | time:0.01s | N/A | N/A | | N/A |
+————————-+———-+———–+—————+——————————–+————————-+———+——+————————–+———————–+
## 4. 验证优化效果
– 查看CPU使用率：top
# 输出示例
top – 10:05:00 up 1 day, 2:05, 2 users, load average: 2.50, 3.20, 4.80
Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie
%Cpu(s): 20.0 us, 5.0 sy, 0.0 ni, 75.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12345 tidb 20 0 8.0g 2.0g 100m S 15.0 25.0 1:35.00 tidb-server
– 查看SQL执行时间
mysql> SET profiling = 1;
mysql> SELECT * FROM fgedu_users WHERE name LIKE ‘test%’;
mysql> SHOW PROFILES;
# 输出示例
+———-+————+————————————————+|
| Query_ID | Duration | Query |
+———-+————+————————————————+|
| 1 | 0.00123456 | SELECT * FROM fgedu_users WHERE name LIKE ‘test%’ |
+———-+————+————————————————+|
4.2.2 系统优化实战
## 1. 问题：CPU核心数不足导致高负载
– 服务器配置：4核CPU
– 业务需求：高并发查询
– CPU使用率：持续90%以上
## 2. 解决方案：增加CPU核心数
– 升级服务器：从4核升级到8核
– 或增加TiDB实例：添加一个4核的TiDB实例
– 配置负载均衡：使用HAProxy或Nginx进行负载均衡
## 3. 配置负载均衡
$ vim /etc/haproxy/haproxy.cfg
frontend tidb-frontend
bind *:4000
mode tcp
default_backend tidb-backend
backend tidb-backend
mode tcp
balance roundrobin
server tidb1 192.168.1.10:4000 check
server tidb2 192.168.1.11:4000 check
## 4. 验证优化效果
– 查看CPU使用率：top
# 输出示例
top – 10:10:00 up 1 day, 2:10, 2 users, load average: 4.50, 3.20, 2.80
Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie
%Cpu(s): 50.0 us, 5.0 sy, 0.0 ni, 45.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12345 tidb 20 0 8.0g 2.0g 100m S 45.0 25.0 1:40.00 tidb-server
12346 tidb 20 0 8.0g 2.0g 100m S 45.0 25.0 1:35.00 tidb-server
– 查看系统响应时间
$ ab -n 1000 -c 100 http://192.168.1.10:4000/
# 输出示例
Requests per second: 1000.00 [#/sec] (mean)
Time per request: 100.00 [ms] (mean)
4.3 CPU优化效果验证
4.3.1 性能测试
## 1. 使用sysbench进行CPU性能测试
$ sysbench cpu –cpu-max-prime=20000 run
# 输出示例
CPU speed:
events per second: 1000.00
General statistics:
total time: 10.0000s
total number of events: 10000
Latency (ms):
min: 1.00
avg: 1.00
max: 1.00
approx. 95 percentile: 1.00
## 2. 使用tpcc进行数据库性能测试
$ tiup bench tpcc –host 192.168.1.10 –port 4000 –user fgedu –password password –db fgedudb –warehouses 100 prepare
$ tiup bench tpcc –host 192.168.1.10 –port 4000 –user fgedu –password password –db fgedudb –warehouses 100 –time 300 run
# 输出示例
[INFO] Benchmark finished, TPM: 10000, QPS: 100000
## 3. 验证优化前后的性能对比
– 优化前：TPM 5000, QPS 50000
– 优化后：TPM 10000, QPS 100000
– 性能提升：100%
4.3.2 监控验证
## 1. 查看CPU使用率趋势
– 登录Grafana：http://192.168.1.10:3000
– 查看CPU使用率面板
– 分析优化前后的CPU使用率变化
## 2. 查看SQL执行时间趋势
– 登录TiDB Dashboard：http://192.168.1.10:2379/dashboard
– 查看SQL语句面板
– 分析优化前后的SQL执行时间变化
## 3. 查看系统响应时间
– 使用ping命令：ping 192.168.1.10
– 使用curl命令：curl -s -o /dev/null -w “%{time_total}\n” http://192.168.1.10:4000/
– 分析优化前后的响应时间变化
## 4. 查看业务指标
– 查看页面响应时间
– 查看业务处理时间
– 查看并发用户数
– 分析优化前后的业务指标变化
Part05-风哥经验总结与分享
5.1 CPU优化最佳实践
CPU优化最佳实践：
- SQL优化：优化SQL语句和索引，减少CPU计算开销
- 系统优化：调整系统参数，提高CPU利用率
- 配置优化：合理配置TiDB参数，根据CPU核心数调整并发度
- 业务优化：错峰处理，避免业务高峰期的CPU竞争
- 架构优化：水平扩展，增加TiDB实例数量，分散CPU负载
- 监控预警：建立CPU监控和预警机制，及时发现和处理CPU高负载
- 容量规划：根据业务需求和增长趋势，合理规划CPU容量
- 持续优化：定期分析CPU使用情况，持续优化系统性能
5.2 CPU高负载预防策略
CPU高负载预防策略：
- 性能测试：在上线前进行充分的性能测试，发现和解决潜在的CPU瓶颈
- 监控预警：设置合理的CPU使用率告警阈值，及时发现CPU高负载
- 容量规划：根据业务增长趋势，提前规划CPU容量
- 代码审查：对SQL语句和应用代码进行审查，避免性能问题
- 索引优化：根据查询模式，合理设计和维护索引
- 并发控制：合理控制并发度，避免CPU资源竞争
- 缓存策略：使用缓存减少数据库访问，降低CPU负载
- 负载均衡：使用负载均衡分散CPU负载
5.3 CPU性能调优技巧
## 1. SQL调优技巧
– 使用EXPLAIN分析执行计划：了解SQL的执行方式
– 添加合适的索引：避免全表扫描
– 优化JOIN操作：使用合适的JOIN类型和顺序
– 减少查询字段：只查询需要的字段
– 批量处理：减少小查询的数量
– 使用绑定变量：减少SQL解析开销
## 2. 系统调优技巧
– 调整CPU调度策略：使用deadline或cfq调度器
– 开启CPU性能模式：echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
– 调整进程优先级：使用nice命令调整进程优先级
– 关闭不必要的服务：减少系统负载
– 使用cgroups限制进程CPU使用：避免单个进程占用过多CPU
## 3. TiDB调优技巧
– 调整max-procs参数：根据CPU核心数设置
– 优化垃圾回收：调整gc-ratio参数
– 优化统计信息更新：使用tidb_analyze_version=2
– 合理设置并发度：根据CPU核心数和业务需求调整
– 启用快速执行计划：设置tidb_enable_fast_plan=1
## 4. 业务调优技巧
– 错峰处理：避开业务高峰期进行批量操作
– 限流：对高并发请求进行限流
– 缓存：使用Redis等缓存减少数据库访问
– 异步处理：将耗时操作改为异步处理
– 批量操作：合并多个小操作为批量操作
## 5. 架构调优技巧
– 读写分离：将读请求分散到多个TiDB实例
– 水平扩展：增加TiDB实例数量
– 分片：将数据分散到多个TiKV节点
– 负载均衡：使用HAProxy或Nginx进行负载均衡
– 微服务架构：将业务拆分为多个微服务，分散CPU负载
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
联系我们
在线咨询：
微信号：itpux-com
工作日：9:30-18:30，节假日休息
