MySQL 5.7性能问题与300 GB Innodb

时间:2017-09-13 07:36:07

标签: mysql

我们在Mysql 5.7上运行数据库,数据库大小约为300 GB。数据库在专用Linux服务器(RHEL 6)上运行,具有144 GB RAM,16个CPU和15 GB交换大小。

服务器忙碌了一整天,最少50个连接。大多数查询都有索引,每周优化一次。但我们仍面临绩效问题。因此请求查看my.cnf配置,并建议更改。

my.cnf如下:

[mysqld]
basedir=/usr
datadir=/sql/mysql/data57
socket=/sql/mysql/data/mysql.sock
skip-external-locking
key_buffer_size = 4000M
max_allowed_packet = 5120M
table_open_cache = 4000
sort_buffer_size = 128M
read_buffer_size =8M
join_buffer_size=128M
read_rnd_buffer_size = 16M
myisam_sort_buffer_size = 128M
thread_cache_size = 100
query_cache_size=0
query_cache_limit=4M
query_cache_type="ON"
query_cache_min_res_unit=20K
query_prealloc_size=40K
query_alloc_block_size=40K
max_connections=300
sql_mode = ""
interactive_timeout = 28800
wait_timeout = 7200
connect_timeout = 60
default_password_lifetime=0
old_passwords=2
lower_case_table_names=1
tmpdir=/tmpfs
tmp_table_size=20G
max_heap_table_size=170M
innodb_buffer_pool_size=100G
innodb_buffer_pool_instances=16
innodb_buffer_pool_chunk_size=6562M
innodb_read_io_threads=64
innodb_write_io_threads=64
innodb_log_file_size=2G
innodb_lock_wait_timeout=180
net_buffer_length=8K
transaction-isolation=READ-COMMITTED
innodb_lock_wait_timeout=180
federated


log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[client]
port=3306
socket=/sql/mysql/data/mysql.sock

[mysql.server]
user=mysql
basedir=/usr
log-bin=mysql-bin
binlog_format=mixed
server-id=1

[mysqldump]
quick
max_allowed_packet=1G

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size=1024M
sort_buffer_size=256K
read_buffer=8M
write_buffer=8M

[mysqlhotcopy]
interactive-timeout

1 个答案:

答案 0 :(得分:1)

我建议使用不同的性能优化方法,与MySQL服务器重新配置无关。

首先,尝试分析您的表结构,看看它们是否具有正确设置的最佳列类型,对于像您这样的大型数据库 - 每一位都很重要:

 SELECT * FROM table PROCEDURE ANALYSE();

PROCEDURE ANALYSE会根据表格中的数据告诉您表格中建议的列类型。这有助于提高读/写表的效率。

第二次,尝试启用所谓的"慢查询日志"然后研究显示在其中的查询。这将帮助您避免由于编写错误的查询而导致的一些可能的灾难性故障,并最终对其进行优化:

SET GLOBAL slow_query_log = 'ON'; 

FLUSH LOGS;

我认为,重要的是找到一种方法来确定具体的性能问题,因此你知道你正在解决正确的问题。考虑使用分析器来查找瓶颈,然后处理该特定问题。