高性能的MySQL(8)优化服务器配置一I/O

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介:

有一些配置项影响着MySQL怎样同步数据到磁盘以及如何做恢复操作,这写操作对性能影响很大,因为都设计到昂贵的I/O操作,通常保证数据立刻并且一致的写到磁盘是很昂贵的,有的时候不得不冒一点险,延迟持久化到磁盘,来增加并发和减少I/O等待。

一、InnoDB I/O配置

对于常见的应用,InnoDB日志文件大小、InnoDB怎样刷新日志缓冲,以及怎样执行I/O比较重要。

182030158.png

a、InnoDB事务日志

InnoDB使用日志来减少提交事务时的开销,日志记录了事务,就无须在每个事务提交时把缓冲池刷新到磁盘中了。一旦日志安全写到磁盘,事务就持久化了,这是必须的,因为日志有固定的大小,而且是环形方式写,写到尾部,会重现跳到开头继续写。InnoDB使用一个后台线程智能刷新这些变更到数据文件。

整体的日志文件大小受控于innodb_log_file_size和innodb_log_files_in_group两个参数,默认情况下只有2个5MB的文件,对高性能工作来说,至少需要几百MB或者上GB。

要修改日志文件大小,必须完全干净的关闭MySQL,否则数据就无法恢复了,最好先备份旧的日志文件。

当InnoDB变更任何数据时,会写一条变更记录到内存日志缓冲区。在缓冲区满的时候,事务提交的时候,或者每一秒,InnoDB都会刷新缓冲区的内容到磁盘日志文件。如果有大事务,增加日志缓冲区(默认1MB)大小可以减少I/O,变量innodb_log_buffer_size控制,几十上百MB都可以。

作为一个经验法则,日志文件的全部大小,应该足够容纳服务器一个小时的活动内容。


当InnoDB把日志缓冲刷新到日志文件时,会先锁住缓冲区,刷新完成,移动剩下的条目到缓冲区前面。日志缓冲必须刷新到持久化存储,以确保提交的事务完全被持久化了。如果和持久相比更在乎性能可以修改innodb_flush_log_at_trx_commit来控制刷新频率,有如下的值

0:

把日志缓冲写到日志文件,并且每秒刷新一次,但是事务提交时不做任何时。

1:

把日志缓冲写到日志文件,并且每次事务提交都刷新到持久化存储。

2:

每次提交时把日志缓冲写到日志文件,但是不刷新,InnoDB每秒做一次刷新。

在大部分操作系统中,把缓冲写到日志只是简单的把数据从InnoDB的内存缓冲转移到操作系统的缓存,么有真正的持久化。

把日志刷新到持久化存储意味着InnoDB请求操作系统把数据刷出缓存,并确认写到磁盘了,这是一个阻塞I/O的调用,知道数据被全部写完。


使用innodb_flush_method选项可以配置InnoDB如何跟踪文件系统相互作用。有如下几个值可以设置,但不一一介绍了。

1、fdatasync

2、0_DIRECT

3、ALL_0_DIRECT

4、0_DSYNC

5、还有几个windows下的配置。


InnoDB把数据保存到表空间内。配置表空间,通过innodb_data_file_path可以定制表空间文件,这写文件都放在innodb_data_home_dir指定目录下:

1
2
innodb_data_home_dir =  /var/lib/mysql/
innodb_data_file_path = ibdata1:1G;ibdata2:2G;

为了允许表空间在超过了分配空间时还能增长,可以配置最后一个文件自动扩展

1
ibdata3:1G:autoextend:max:2G

限制最多扩展到2G。

管理一个单独的表空间有点麻烦,innodb_file_per_table选项可以让InnoDB为每张表使用一个文件。存储为”表名.ibd“的文件,这个在之前的分区技术里已经做过试验了,有实际的截图,大家可以看看。虽然易于管理,但是也有缺点:

每张表使用自己的表空间,移除表空间实际上需要InnoDB锁定和扫描缓冲池,查找属于这个表的空间的页面,在一个庞大的缓冲池主哦姑娘,这个非常慢。但是Percona Server有一个修复的选项 innodb_lazy_drop_table。


二、MyISAM的I/O配置


MyISAM通常每次写操作都会把索引变更刷新到磁盘,所以批量操作会更快一些,lock table是一种办法。

通过设置delay_key_write变量也可以延迟索引的写入,这样修改的键缓冲知道表关闭才会被刷新,可能的配置如下:

OFF:

每次写操作后刷新键缓冲,除非表被lock tables锁定了。

ON:

打开延迟键写入,只对delay_key_write选项创建的表有效。

ALL:

所有MyISAM表都会延迟键写入。


另外除了MyISAM索引的I/O还可以配置MyISAM怎样尝试从损坏中修复

myisam_recover选项可以控制,可以设置的值如下:

DEFAULT(或者不设置):

尝试修复任何被标记为崩溃或者么有标记为完全关闭的表。

BACKUP:

将数据文件备份到.BAK文件,以便随后进行检查。

FORCE:

即使.MYD文件中丢失的数据超过一行,也让恢复继续。

QUICK:

除非有删除块,否则跳过恢复。块中已经删除的行也会占用空间,但是可以被后面的insert语句重用。

我们建议打开这个选项,尤其是只有一些小的MyISAM表时,服务器运行一些损坏的MyISAM表是很危险的。然而如果表很大,这是个低效的做法,比较好的主意是启动后用check tables和repair tables命令来做。


















本文转自shayang8851CTO博客,原文链接:http://blog.51cto.com/janephp/1320547,如需转载请自行联系原作者

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
4月前
|
存储 弹性计算 安全
阿里云轻量服务器通用型、CPU优化型、多公网IP型、国际型、容量型不同实例区别与选择参考
阿里云轻量应用服务器实例类型分为通用型、CPU优化型、多公网IP型、国际型、容量型,不同规格族的适用场景和特点不同,收费标准也不一样。本文为大家介绍轻量应用服务器通用型、多公网IP型、容量型有何区别?以及选择参考。
|
3月前
|
存储 缓存 监控
MySQL服务器配置优化:my.cnf参数调优指南
本文深入解析了MySQL核心配置参数及性能优化技巧,涵盖内存结构、调优原则、存储引擎优化、查询性能优化等内容,通过实战案例帮助读者构建高性能MySQL服务器配置,解决常见的性能瓶颈问题。
|
7月前
|
存储 弹性计算 缓存
阿里云服务器ECS实例选型与性能监控指南:从场景匹配到优化参考
随着云服务器的普及应用,越来越多的企业和个人用户选择将业务迁移到云端,以享受其带来的灵活性、可扩展性和成本效益。阿里云服务器(Elastic Compute Service,简称ECS)以其丰富的实例规格、卓越的性能和稳定的运行环境,赢得了广大用户的信赖。然而,对于很多初次接触云服务器产品的新手用户来说,面对阿里云多达几十种的云服务器实例规格,往往感到无从下手,不知道如何选择最适合自己业务需求的实例规格。本文旨在通过详细解析阿里云ECS实例规格的选择策略,并介绍如何有效监控云服务器性能,确保业务的高效运行。
440 63
|
2月前
|
存储 缓存 安全
阿里云轻量应用服务器实例:通用型、多公网IP型、CPU优化、国际及容量型区别对比
阿里云轻量服务器分通用型、CPU优化型、多公网IP型、国际型和容量型。通用型适合网站与应用;CPU优化型提供稳定高性能计算;多公网IP型支持2-3个IP,适用于账号管理;国际型覆盖海外地域,助力出海业务;容量型提供大存储,适配网盘与实训场景。
236 1
|
6月前
|
SQL 缓存 关系型数据库
MySQL 慢查询是怎样优化的
本文深入解析了MySQL查询速度变慢的原因及优化策略,涵盖查询缓存、执行流程、SQL优化、执行计划分析(如EXPLAIN)、查询状态查看等内容,帮助开发者快速定位并解决慢查询问题。
255 0
|
3月前
|
存储 缓存 数据挖掘
阿里云轻量应用服务器“CPU优化型”配置介绍、费用价格说明
阿里云轻量应用服务器推出CPU优化型,提供更强计算性能,2核4GB起,最高16核64GB,全系支持200Mbps带宽。适用于企业级应用、数据库、游戏服务器等高算力场景,保障稳定高效运行。
421 1
|
4月前
|
缓存 关系型数据库 MySQL
降低MySQL高CPU使用率的优化策略。
通过上述方法不断地迭代改进,在实际操作中需要根据具体场景做出相对合理判断。每一步改进都需谨慎评估其变动可能导致其他方面问题,在做任何变动前建议先在测试环境验证其效果后再部署到生产环境中去。
211 6
|
5月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分,阐述了 char 与 varchar 在存储方式和性能上的差异,以及事务的 ACID 特性、并发事务问题及对应的隔离级别(MySQL 默认 REPEATABLE READ)。 索引基础部分,详解了 InnoDB 默认的 B+tree 索引结构(多路平衡树、叶子节点存数据、双向链表支持区间查询),区分了聚簇索引(数据与索引共存,唯一)和二级索引(数据与索引分离,多个),解释了回表查询的概念及优化方法,并分析了 B+tree 作为索引结构的优势(树高低、效率稳、支持区间查询)。 索引优化部分,列出了索引创建的六大原则
137 2
|
5月前
|
安全
基于Reactor模式的高性能服务器之Acceptor组件(处理连接)
本节介绍了对底层 Socket 进行封装的设计与实现,通过 `Socket` 类隐藏系统调用细节,提供简洁、安全、可读性强的接口。重点包括 `Socket` 类的核心作用(管理 `sockfd_`)、成员函数的功能(如绑定地址、监听、接受连接等),以及 `Acceptor` 组件的职责:监听连接、接收新客户端连接并分发给上层处理。同时说明了 `Acceptor` 与 `EventLoop` 和 `TcpServer` 的协作关系,并展示了其成员变量和关键函数的工作机制。
127 2
|
4月前
|
缓存 监控 前端开发
详述uniapp项目部署于Nginx服务器的配置优化方法。
综上所述,uniapp项目部署于Nginx的优化方法多种多样,应根据实际情况灵活地采取合适的策略。配置后持续监控和调试,适时调整配置以保持最佳性能,并确保随着应用需求和访问模式的变化,服务器配置得到适当的更新和优化。
221 0

热门文章

最新文章

推荐镜像

更多