2. 首页 > 国产数据库教程 > GoldenDB教程 > 正文

GoldenDB教程FG023-GoldenDB系统性能-SQL 性能与业务压测优化实战

教程整理：风哥教程  |  更新时间：2026-02-01  |  教程分类：GoldenDB教程  |  文档学习：1

本文主要介绍GoldenDB数据库的系统性能优化、SQL性能调优以及业务压测的实战方法。风哥教程参考GoldenDB官方文档GoldenDB8系统管理员手册、GoldenDB8性能调优等相关文档。

通过本文的学习，您将掌握GoldenDB性能优化的核心技术，学会如何进行SQL调优和业务压测，以及如何分析和解决性能瓶颈问题。

本教程适用于GoldenDB数据库管理员、开发人员和性能工程师，帮助您在生产环境中优化数据库性能，提升系统的稳定性和响应速度。

目录大纲

Part01-基础概念与理论知识

Part02-生产环境规划与建议

Part03-生产环境项目实施方案

Part04-生产案例与实战讲解

Part05-风哥经验总结与分享

Part01-基础概念与理论知识

1.1 GoldenDB性能优化概述

GoldenDB性能优化是一个系统工程，涉及多个层面：

  • 硬件层面：服务器配置、存储系统、网络带宽等
  • 系统层面：操作系统参数、文件系统、内核优化等
  • 数据库层面：参数配置、索引设计、SQL优化等
  • 应用层面：应用程序设计、连接管理、事务处理等

性能优化的目标是在满足业务需求的前提下，提高系统的响应速度、吞吐量和稳定性。

更多视频教程www.fgedu.net.cn

1.2 SQL执行原理与优化基础

SQL语句的执行过程包括以下步骤：

  • 解析：分析SQL语句的语法和语义
  • 优化：生成执行计划，选择最优的执行路径
  • 执行：按照执行计划执行SQL语句
  • 返回：返回执行结果

SQL优化的核心是通过分析执行计划，找出性能瓶颈，然后采取相应的优化措施，如创建索引、重写SQL语句等。

学习交流加群风哥微信: itpux-com

1.3 业务压测原理与方法

业务压测是通过模拟真实的业务负载，测试系统在不同压力下的性能表现。主要包括：

  • 基准测试：测试系统的基本性能指标
  • 负载测试：测试系统在不同负载下的性能
  • 压力测试：测试系统的极限性能
  • 稳定性测试：测试系统在长时间运行下的稳定性

常用的压测工具包括sysbench、tpcc、Jmeter等。

学习交流加群风哥QQ113257174

Part02-生产环境规划与建议

2.1 硬件资源规划

在生产环境中，硬件资源规划需要考虑以下因素：

  • CPU：根据业务并发量和计算需求选择合适的CPU核心数和主频
  • 内存：根据数据库大小和缓存需求配置足够的内存
  • 存储：使用高速存储设备，如SSD，配置合理的RAID级别
  • 网络：确保网络带宽足够，减少网络延迟

风哥提示：对于GoldenDB分布式集群，建议将不同组件部署在独立的服务器上，避免资源竞争。

2.2 系统参数优化

操作系统参数优化建议：

# 内核参数优化
# /etc/sysctl.conf

# 最大文件句柄数
fs.file-max = 6815744

# 网络参数
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15

# 内存参数
vm.swappiness = 10
vm.overcommit_memory = 2

# 进程参数
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmall = 1073741824
kernel.shmmax = 4398046511104

# 应用内核参数
# sysctl -p

fs.file-max = 6815744
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15
vm.swappiness = 10
vm.overcommit_memory = 2
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmall = 1073741824
kernel.shmmax = 4398046511104

更多学习教程公众号风哥教程itpux_com

2.3 压测环境准备

压测环境准备包括：

  • 环境隔离：确保压测环境与生产环境隔离，避免影响生产系统
  • 数据准备：准备与生产环境相似的数据量和数据分布
  • 工具安装：安装所需的压测工具，如sysbench、tpcc等
  • 监控配置：配置监控系统，收集压测过程中的性能指标

from GoldenDB视频:www.itpux.com

Part03-生产环境项目实施方案

3.1 SQL性能调优步骤

SQL性能调优的基本步骤：

  1. 识别慢查询：通过慢查询日志或性能监控工具识别慢查询
  2. 分析执行计划：使用EXPLAIN命令分析SQL语句的执行计划
  3. 定位瓶颈：找出SQL执行中的性能瓶颈
  4. 采取优化措施：如创建索引、重写SQL语句等
  5. 验证优化效果：执行优化后的SQL语句，验证性能是否提升

3.2 系统参数调优

GoldenDB系统参数调优建议：

# 登录GoldenDB数据库
$ mysql -h 192.168.1.10 -P 3306 -u fgedu -p

Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1001
Server version: 8.0.28 GoldenDB 8.0.28-1.0.0-log

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql>

# 查看当前参数配置
mysql> SHOW VARIABLES LIKE ‘%buffer%’;

+————————-+—————-+———————————-+
| Variable_name | Value | Description |
+————————-+—————-+———————————-+
| innodb_buffer_pool_size | 134217728 | Size of the InnoDB buffer pool |
| key_buffer_size | 16777216 | Size of the MyISAM key buffer |
| read_buffer_size | 131072 | Size of read buffer for MyISAM |
| read_rnd_buffer_size | 262144 | Size of random read buffer |
| sort_buffer_size | 2097152 | Size of sort buffer |
| join_buffer_size | 2097152 | Size of join buffer |
+————————-+—————-+———————————-+
6 rows in set (0.00 sec)

# 调整InnoDB缓冲池大小（设置为物理内存的70%）
mysql> SET GLOBAL innodb_buffer_pool_size = 10737418240; — 10GB

Query OK, 0 rows affected (0.00 sec)

# 调整连接池大小
mysql> SET GLOBAL max_connections = 1000;

Query OK, 0 rows affected (0.00 sec)

3.3 压测方案设计与执行

压测方案设计包括：

  • 确定压测目标：如TPS、响应时间、并发用户数等
  • 设计测试场景：模拟真实的业务场景，如查询、插入、更新等
  • 设置压测参数：如并发数、压测时间、数据量等
  • 执行压测：使用压测工具执行测试
  • 分析结果：分析压测结果，找出性能瓶颈

Part04-生产案例与实战讲解

4.1 SQL性能调优实战

案例：优化一个慢查询SQL

# 查看慢查询日志
# tail -n 10 /goldendb/fgdata/slow.log

# Time: 2024-01-01T10:00:00.000000Z
# User@Host: fgedu[ fgedu] @ 192.168.1.20 [192.168.1.20]
# Query_time: 5.234567 Lock_time: 0.000123 Rows_sent: 100 Rows_examined: 1000000
SELECT * FROM fgedu_order o JOIN fgedu_user u ON o.user_id = u.id WHERE o.order_date >= ‘2024-01-01’ AND u.age > 30;

# 分析执行计划
mysql> EXPLAIN SELECT * FROM fgedu_order o JOIN fgedu_user u ON o.user_id = u.id WHERE o.order_date >= ‘2024-01-01’ AND u.age > 30;

+—-+————-+——-+————+——+—————+——+———+——+———+———-+————-+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+—-+————-+——-+————+——+—————+——+———+——+———+———-+————-+
| 1 | SIMPLE | o | NULL | ALL | NULL | NULL | NULL | NULL | 1000000 | 10.00 | Using where |
| 1 | SIMPLE | u | NULL | ALL | NULL | NULL | NULL | NULL | 500000 | 33.33 | Using where |
+—-+————-+——-+————+——+—————+——+———+——+———+———-+————-+
2 rows in set, 1 warning (0.00 sec)

风哥提示：执行计划显示两个表都在进行全表扫描，没有使用索引，这是导致查询缓慢的主要原因。

# 创建索引
mysql> CREATE INDEX idx_order_date ON fgedu_order(order_date);
mysql> CREATE INDEX idx_user_id ON fgedu_order(user_id);
mysql> CREATE INDEX idx_age ON fgedu_user(age);
mysql> CREATE INDEX idx_id ON fgedu_user(id);

Query OK, 0 rows affected (1.23 sec)
Records: 0 Duplicates: 0 Warnings: 0

Query OK, 0 rows affected (1.56 sec)
Records: 0 Duplicates: 0 Warnings: 0

Query OK, 0 rows affected (1.02 sec)
Records: 0 Duplicates: 0 Warnings: 0

Query OK, 0 rows affected (0.87 sec)
Records: 0 Duplicates: 0 Warnings: 0

# 再次分析执行计划
mysql> EXPLAIN SELECT * FROM fgedu_order o JOIN fgedu_user u ON o.user_id = u.id WHERE o.order_date >= ‘2024-01-01’ AND u.age > 30;

+—-+————-+——-+————+——-+————————-+—————–+———+——————+——–+———-+————-+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+—-+————-+——-+————+——-+————————-+—————–+———+——————+——–+———-+————-+
| 1 | SIMPLE | o | NULL | range | idx_order_date,idx_user_id | idx_order_date | 3 | NULL | 100000 | 100.00 | Using where |
| 1 | SIMPLE | u | NULL | eq_ref | idx_id,idx_age | idx_id | 4 | fgedudb.o.user_id | 1 | 33.33 | Using where |
+—-+————-+——-+————+——-+————————-+—————–+———+——————+——–+———-+————-+
2 rows in set, 1 warning (0.00 sec)

风哥提示：执行计划显示现在使用了索引，rows值从100万减少到10万，查询性能会显著提升。

4.2 系统性能优化实战

案例：优化GoldenDB集群性能

# 查看集群状态
$ gcluster –status

Cluster status: OK

CN nodes:
cn1: 192.168.1.10:3306 (MASTER)
cn2: 192.168.1.11:3306 (SLAVE)

DN nodes:
dn1: 192.168.1.12:3307 (MASTER)
dn2: 192.168.1.13:3307 (SLAVE)
dn3: 192.168.1.14:3307 (MASTER)
dn4: 192.168.1.15:3307 (SLAVE)

GTM nodes:
gtm1: 192.168.1.16:2379 (MASTER)
gtm2: 192.168.1.17:2379 (SLAVE)

MDS nodes:
mds1: 192.168.1.18:2380 (MASTER)
mds2: 192.168.1.19:2380 (SLAVE)

# 查看CN节点的连接数
mysql> SHOW GLOBAL STATUS LIKE ‘Threads_connected’;

+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| Threads_connected | 500 |
+——————-+——-+

# 调整CN节点的连接池大小
mysql> SET GLOBAL max_connections = 1500;

Query OK, 0 rows affected (0.00 sec)

4.3 业务压测实战

使用sysbench进行压测

# 安装sysbench
# yum install -y sysbench

Loaded plugins: langpacks, ulninfo
Resolving Dependencies
–> Running transaction check
—> Package sysbench.x86_64 0:1.0.20-2.el7 will be installed
–> Processing Dependency: libmysqlclient.so.18()(64bit) for package: sysbench-1.0.20-2.el7.x86_64
–> Processing Dependency: libmysqlclient.so.18(libmysqlclient_18)(64bit) for package: sysbench-1.0.20-2.el7.x86_64
–> Running transaction check
—> Package mariadb-libs.x86_64 1:5.5.68-1.el7 will be installed
–> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
sysbench x86_64 1.0.20-2.el7 epel 281 k
Installing for dependencies:
mariadb-libs x86_64 1:5.5.68-1.el7 base 769 k

Transaction Summary
================================================================================
Install 1 Package (+1 Dependent package)

Total download size: 1.0 M
Installed size: 3.5 M
Downloading packages:
(1/2): mariadb-libs-5.5.68-1.el7.x86_64.rpm | 769 kB 00:00
(2/2): sysbench-1.0.20-2.el7.x86_64.rpm | 281 kB 00:00
——————————————————————————-
Total 1.3 MB/s | 1.0 MB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : 1:mariadb-libs-5.5.68-1.el7.x86_64 1/2
Installing : sysbench-1.0.20-2.el7.x86_64 2/2
Verifying : 1:mariadb-libs-5.5.68-1.el7.x86_64 1/2
Verifying : sysbench-1.0.20-2.el7.x86_64 2/2

Installed:
sysbench.x86_64 0:1.0.20-2.el7

Dependency Installed:
mariadb-libs.x86_64 1:5.5.68-1.el7

Complete!

# 准备测试数据
$ sysbench –db-driver=mysql –mysql-host=192.168.1.10 –mysql-port=3306 –mysql-user=fgedu –mysql-password=fgedu123 –mysql-db=fgedudb –table_size=1000000 –tables=10 prepare

sysbench 1.0.20 (using system LuaJIT 2.0.4)

Creating table ‘sbtest1’…
Inserting 1000000 records into ‘sbtest1’
Creating secondary indexes on ‘sbtest1’…
Creating table ‘sbtest2’…
Inserting 1000000 records into ‘sbtest2’
Creating secondary indexes on ‘sbtest2’…
Creating table ‘sbtest3’…
Inserting 1000000 records into ‘sbtest3’
Creating secondary indexes on ‘sbtest3’…
Creating table ‘sbtest4’…
Inserting 1000000 records into ‘sbtest4’
Creating secondary indexes on ‘sbtest4’…
Creating table ‘sbtest5’…
Inserting 1000000 records into ‘sbtest5’
Creating secondary indexes on ‘sbtest5’…
Creating table ‘sbtest6’…
Inserting 1000000 records into ‘sbtest6’
Creating secondary indexes on ‘sbtest6’…
Creating table ‘sbtest7’…
Inserting 1000000 records into ‘sbtest7’
Creating secondary indexes on ‘sbtest7’…
Creating table ‘sbtest8’…
Inserting 1000000 records into ‘sbtest8’
Creating secondary indexes on ‘sbtest8’…
Creating table ‘sbtest9’…
Inserting 1000000 records into ‘sbtest9’
Creating secondary indexes on ‘sbtest9’…
Creating table ‘sbtest10’…
Inserting 1000000 records into ‘sbtest10’
Creating secondary indexes on ‘sbtest10’…

# 执行压测
$ sysbench –db-driver=mysql –mysql-host=192.168.1.10 –mysql-port=3306 –mysql-user=fgedu –mysql-password=fgedu123 –mysql-db=fgedudb –table_size=1000000 –tables=10 –threads=100 –time=300 –report-interval=10 run

sysbench 1.0.20 (using system LuaJIT 2.0.4)

Running the test with following options:
Number of threads: 100
Report intermediate results every 10 second(s)
Initializing random number generator from current time

Initializing worker threads…

Threads started!

[ 10s ] thds: 100 tps: 1234.56 qps: 24691.23 (r/w/o: 17283.86/4938.24/2469.13) lat (ms,95%): 12.34 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 100 tps: 1245.67 qps: 24913.45 (r/w/o: 17439.41/4982.69/2491.35) lat (ms,95%): 11.98 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 100 tps: 1238.90 qps: 24778.01 (r/w/o: 17344.61/4955.60/2477.80) lat (ms,95%): 12.12 err/s: 0.00 reconn/s: 0.00
…
[ 300s ] thds: 100 tps: 1240.12 qps: 24802.45 (r/w/o: 17361.71/4960.49/2480.25) lat (ms,95%): 12.05 err/s: 0.00 reconn/s: 0.00

SQL statistics:
queries performed:
read: 5208513
write: 1488147
other: 744073
total: 7440733
transactions:
total: 372036 (1240.12 per sec.)
queries: 7440733 (24802.45 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)

General statistics:
total time: 300.0059s
total number of events: 372036

Latency (ms):
min: 2.12
avg: 8.06
max: 45.67
approx. 95th percentile: 12.05

Threads fairness:
events (avg/stddev): 3720.3600/12.34
execution time (avg/stddev): 300.0059/0.00

Part05-风哥经验总结与分享

5.1 性能优化最佳实践

  • 定期分析慢查询：每周至少分析一次慢查询日志，及时发现和优化性能问题
  • 合理设计索引：为常用查询字段创建索引，避免过度索引
  • 优化SQL语句：避免使用SELECT *，只查询必要的字段；使用JOIN代替子查询
  • 调整系统参数：根据服务器配置和业务需求调整数据库参数
  • 监控系统性能：建立完善的监控体系，及时发现性能瓶颈
  • 定期压测：定期进行业务压测，了解系统性能极限

5.2 常见性能问题与解决方案

  • CPU使用率过高：
    • 原因：SQL语句执行效率低，并发量过大
    • 解决方案：优化SQL语句，增加索引，调整并发参数
  • 内存使用过高：
    • 原因：缓冲池设置过大，连接数过多
    • 解决方案：调整缓冲池大小，优化连接管理
  • I/O性能瓶颈：
    • 原因：存储设备性能不足，SQL语句产生大量I/O操作
    • 解决方案：使用SSD存储，优化SQL语句，增加缓存
  • 网络延迟：
    • 原因：网络带宽不足，网络设备性能问题
    • 解决方案：增加网络带宽，优化网络设备

5.3 压测结果分析与调优建议

压测结果分析要点：

  • TPS/QPS：事务处理能力和查询处理能力
  • 响应时间：95%和99%响应时间是否符合要求
  • 资源使用率：CPU、内存、I/O等资源的使用情况
  • 错误率：是否有错误发生

调优建议：

  • 根据压测结果调整系统参数
  • 优化SQL语句和索引
  • 增加硬件资源或优化硬件配置
  • 调整应用程序设计，减少数据库负载

风哥提示：性能优化是一个持续的过程，需要定期监控和调整，根据业务需求和系统变化进行优化。

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息