超详细MySQL数据库优化

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了超详细MySQL数据库优化相关的知识，希望对你有一定的参考价值。

参考技术A

数据库优化一方面是找出系统的瓶颈,提高mysql数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.

1. 优化一览图

2. 优化

笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置.

2.1 软优化

2.1.1 查询语句优化

1.首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.

2.例:

显示:

其中会显示索引和查询数据读取数据条数等信息.

2.1.2 优化子查询

在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.

2.1.3 使用索引

索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项:

2.1.4 分解表

对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,

2.1.5 中间表

对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.

2.1.6 增加冗余字段

类似于创建中间表,增加冗余也是为了减少连接查询.

2.1.7 分析表,,检查表,优化表

分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.

1. 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;

2. 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]

option 只对MyISAM有效,共五个参数值:

3. 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志.,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁.

2.2 硬优化

2.2.1 硬件三件套

1.配置多核心和频率高的cpu,多核心可以执行多个线程.

2.配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.

3.配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力.

2.2.2 优化数据库参数

优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能.MySQL服务的配置参数都在my.cnf或my.ini,下面列出性能影响较大的几个参数.

2.2.3 分库分表

因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。另外一个，压力过大把你的数据库给搞挂了怎么办？所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这时作为主库承载写入请求。然后每个主库都挂载至少一个从库，由从库来承载读请求。

2.2.4 缓存集群

如果用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果你就是简单的不停的加机器，其实是不对的。所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。

一个完整而复杂的高并发系统架构中，一定会包含：各种复杂的自研基础架构系统。各种精妙的架构设计.因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了.

一份超详细的MySQL高性能优化实战总结！

MySQL 对于很多 Linux 从业者而言，是一个非常棘手的问题，多数情况都是因为对数据库出现问题的情况和处理思路不清晰。

 

技术图片

 

 

在进行 MySQL 的优化之前必须要了解的就是 MySQL 的查询过程，很多的查询优化工作实际上就是遵循一些原则让 MySQL 的优化器能够按照预想的合理方式运行而已。

 

技术图片

 

 

MySQL 查询过程

优化的哲学

注：优化有风险，修改需谨慎。

  • 优化可能带来的问题：
  • 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。
  • 优化手段本来就有很大的风险，只不过你没能力意识到和预见到。
  • 任何的技术可以解决一个问题，但必然存在带来一个问题的风险。
  • 对于优化来说解决问题而带来的问题，控制在可接受的范围内才是有成果。
  • 保持现状或出现更差的情况都是失败。

优化的需求：

  • 稳定性和业务可持续性，通常比性能更重要。
  • 优化不可避免涉及到变更，变更就有风险。
  • 优化使性能变好，维持和变差是等概率事件。
  • 切记优化，应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化。

所以优化工作，是由业务需求驱使的!

优化由谁参与?在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。

优化思路

优化什么

在数据库优化上有两个主要方面：

  • 安全：数据可持续性。
  • 性能：数据的高性能访问。

优化的范围有哪些

存储、主机和操作系统方面：

  • 主机架构稳定性
  • I/O 规划及配置
  • Swap 交换分区
  • OS 内核参数和网络问题

应用程序方面：

  • 应用程序稳定性
  • SQL 语句性能
  • 串行访问资源
  • 性能欠佳会话管理
  • 这个应用适不适合用 MySQL

数据库优化方面：

  • 内存
  • 数据库结构(物理&逻辑)
  • 实例配置

说明：不管是设计系统、定位问题还是优化，都可以按照这个顺序执行。

优化维度

 

技术图片

 

 

数据库优化维度有如下四个：

  • 硬件
  • 系统配置
  • 数据库表结构
  • SQL 及索引

优化选择：

  • 优化成本：硬件>系统配置>数据库表结构>SQL 及索引。
  • 优化效果：硬件<系统配置<数据库表结构

优化工具有啥

数据库层面

检查问题常用的 12 个工具：

  • MySQL
  • mysqladmin：MySQL 客户端，可进行管理操作
  • mysqlshow：功能强大的查看 shell 命令
  • SHOW [SESSION | GLOBAL] variables：查看数据库参数信息
  • SHOW [SESSION | GLOBAL] STATUS：查看数据库的状态信息
  • information_schema：获取元数据的方法
  • SHOW ENGINE INNODB STATUS：Innodb 引擎的所有状态
  • SHOW PROCESSLIST：查看当前所有连接的 session 状态
  • explain：获取查询语句的执行计划
  • show index：查看表的索引信息
  • slow-log：记录慢查询语句
  • mysqldumpslow：分析 slowlog 文件的工具

不常用但好用的 7 个工具：

  • Zabbix：监控主机、系统、数据库(部署 Zabbix 监控平台)
  • pt-query-digest：分析慢日志
  • MySQL slap：分析慢日志
  • sysbench：压力测试工具
  • MySQL profiling：统计数据库整体状态工具
  • Performance Schema：MySQL 性能状态统计的数据
  • workbench：管理、备份、监控、分析、优化工具(比较费资源)

关于 Zabbix 参考：http://www.cnblogs.com/clsn/p/7885990.html

数据库层面问题解决思路

一般应急调优的思路：针对突然的业务办理卡顿，无法进行正常的业务处理，需要马上解决的场景。

show processlist 
explain select id ,name from stu where name=‘clsn‘; # ALL id name age sex 
 select id,name from stu where id=2-1 函数 结果集>30; 
　 show index from table; 
通过执行计划判断，索引问题（有没有、合不合理）或者语句本身问题 
show status like ‘%lock%‘; # 查询锁状态 
kill SESSION_ID; # 杀掉有问题的session

常规调优思路：针对业务周期性的卡顿，例如在每天 10-11 点业务特别慢，但是还能够使用，过了这段时间就好了。

查看slowlog，分析slowlog，分析出查询慢的语句； 
按照一定优先级，一个一个排查所有慢语句； 
分析top SQL，进行explain调试，查看语句执行时间； 
调整索引或语句本身。

系统层面

CPU方面：vmstat、sar top、htop、nmon、mpstat。

内存：free、ps-aux。

IO 设备(磁盘、网络)：iostat、ss、netstat、iptraf、iftop、lsof。

vmstat 命令说明：

  • Procs：r 显示有多少进程正在等待 CPU 时间。b 显示处于不可中断的休眠的进程数量。在等待 I/O。
  • Memory：swpd 显示被交换到磁盘的数据块的数量。未被使用的数据块，用户缓冲数据块，用于操作系统的数据块的数量。
  • Swap：操作系统每秒从磁盘上交换到内存和从内存交换到磁盘的数据块的数量。s1 和 s0 最好是 0。
  • IO：每秒从设备中读入 b1 的写入到设备 b0 的数据块的数量。反映了磁盘 I/O。
  • System：显示了每秒发生中断的数量(in)和上下文交换(cs)的数量。
  • CPU：显示用于运行用户代码，系统代码，空闲，等待 I/O 的 CPU 时间。

iostat 命令说明：

  • 实例命令：iostat -dk 1 5;iostat -d -k -x 5 (查看设备使用率(%util)和响应时间(await))。
  • TPS：该设备每秒的传输次数。“一次传输”意思是“一次 I/O 请求”。多个逻辑请求可能会被合并为“一次 I/O 请求”。
  • iops ：硬件出厂的时候，厂家定义的一个每秒最大的 IO 次数。
  • "一次传输"请求的大小是未知的。
  • KB_read/s：每秒从设备(drive expressed)读取的数据量。
  • KB_wrtn/s：每秒向设备(drive expressed)写入的数据量。
  • KB_read：读取的总数据量。
  • KB_wrtn：写入的总数量数据量;这些单位都为 Kilobytes。

系统层面问题解决办法

你认为到底负载高好，还是低好呢?在实际的生产中，一般认为 CPU 只要不超过 90% 都没什么问题。当然不排除下面这些特殊情况。

CPU 负载高，IO 负载低：

  • 内存不够
  • 磁盘性能差
  • SQL 问题：去数据库层，进一步排查 SQL 问题
  • IO 出问题了(磁盘到临界了、raid 设计不好、raid 降级、锁、在单位时间内 TPS 过高)
  • TPS 过高：大量的小数据 IO、大量的全表扫描

IO 负载高，CPU 负载低：

  • 大量小的 IO 写操作
  • autocommit，产生大量小 IO;IO/PS，磁盘的一个定值，硬件出厂的时候，厂家定义的一个每秒最大的 IO 次数。
  • 大量大的 IO 写操作：SQL 问题的几率比较大

IO和 CPU 负载都很高：

  • 硬件不够了或 SQL 存在问题

基础优化

优化思路

定位问题点吮吸：硬件>系统>应用>数据库>架构(高可用、读写分离、分库分表)。

处理方向：明确优化目标、性能和安全的折中、防患未然。

硬件优化

①主机方面

根据数据库类型，主机 CPU 选择、内存容量选择、磁盘选择：

  • 平衡内存和磁盘资源
  • 随机的 I/O 和顺序的 I/O
  • 主机 RAID 卡的 BBU(Battery Backup Unit)关闭

②CPU 的选择

CPU 的两个关键因素：核数、主频。根据不同的业务类型进行选择：

  • CPU 密集型：计算比较多，OLTP 主频很高的 CPU、核数还要多。
  • IO 密集型：查询比较，OLAP 核数要多，主频不一定高的。

③内存的选择

OLAP 类型数据库，需要更多内存，和数据获取量级有关。OLTP 类型数据一般内存是 CPU 核心数量的 2 倍到 4 倍，没有最佳实践。

④存储方面

根据存储数据种类的不同，选择不同的存储设备，配置合理的 RAID 级别(raid5、raid10、热备盘)。

对于操作系统来讲，不需要太特殊的选择，最好做好冗余(raid1)(ssd、sas、sata)。

主机 raid 卡选择：

  • 实现操作系统磁盘的冗余(raid1)
  • 平衡内存和磁盘资源
  • 随机的 I/O 和顺序的 I/O
  • 主机 raid 卡的 BBU(Battery Backup Unit)要关闭

⑤网络设备方面

使用流量支持更高的网络设备(交换机、路由器、网线、网卡、HBA 卡)。注意：以上这些规划应该在初始设计系统时就应该考虑好。

服务器硬件优化

服务器硬件优化关键点：

  • 物理状态灯
  • 自带管理设备：远程控制卡(FENCE设备：ipmi ilo idarc)、开关机、硬件监控。
  • 第三方的监控软件、设备(snmp、agent)对物理设施进行监控。
  • 存储设备：自带的监控平台。EMC2(HP 收购了)、 日立(HDS)、IBM 低端 OEM HDS、高端存储是自己技术，华为存储。

系统优化

CPU：基本不需要调整，在硬件选择方面下功夫即可。

内存：基本不需要调整，在硬件选择方面下功夫即可。

SWAP：MySQL 尽量避免使用 Swap。阿里云的服务器中默认 swap 为 0。

IO ：raid、no lvm、ext4 或 xfs、ssd、IO 调度策略。

Swap 调整(不使用 swap 分区)：

/proc/sys/vm/swappiness的内容改成0(临时)，/etc/sysctl. conf上添加vm.swappiness=0(永久)

这个参数决定了 Linux 是倾向于使用 Swap，还是倾向于释放文件系统 Cache。在内存紧张的情况下，数值越低越倾向于释放文件系统 Cache。

当然，这个参数只能减少使用 Swap 的概率，并不能避免 Linux 使用 Swap。

修改 MySQL 的配置参数 innodb_flush_ method，开启 O_DIRECT 模式。

这种情况下，InnoDB 的 buffer pool 会直接绕过文件系统 Cache 来访问磁盘，但是 redo log 依旧会使用文件系统 Cache。

值得注意的是，Redo log 是覆写模式的，即使使用了文件系统的 Cache，也不会占用太多。

IO 调度策略：

#echo deadline>/sys/block/sda/queue/scheduler 临时修改为deadline

永久修改：

vi /boot/grub/grub.conf 
更改到如下内容: 
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet

系统参数调整

Linux 系统内核参数优化：

vim/etc/sysctl.conf 
net.ipv4.ip_local_port_range = 1024 65535：# 用户端口范围 
net.ipv4.tcp_max_syn_backlog = 4096 
net.ipv4.tcp_fin_timeout = 30 
fs.file-max=65535：# 系统最大文件句柄，控制的是能打开文件最大数量

用户限制参数(MySQL 可以不设置以下配置)：

vim/etc/security/limits.conf 
* soft nproc 65535 
* hard nproc 65535 
* soft nofile 65535 
* hard nofile 65535

应用优化

业务应用和数据库应用独立。

防火墙：iptables、selinux 等其他无用服务(关闭)：

chkconfig --level 23456 acpid off 
 chkconfig --level 23456 anacron off 
 chkconfig --level 23456 autofs off 
 chkconfig --level 23456 avahi-daemon off 
 chkconfig --level 23456 bluetooth off 
 chkconfig --level 23456 cups off 
 chkconfig --level 23456 firstboot off 
 chkconfig --level 23456 haldaemon off 
 chkconfig --level 23456 hplip off 
 chkconfig --level 23456 ip6tables off 
 chkconfig --level 23456 iptables off 
 chkconfig --level 23456 isdn off 
 chkconfig --level 23456 pcscd off 
 chkconfig --level 23456 sendmail off 
 chkconfig --level 23456 yum-updatesd off

安装图形界面的服务器不要启动图形界面 runlevel 3。

另外，思考将来我们的业务是否真的需要 MySQL，还是使用其他种类的数据库。用数据库的最高境界就是不用数据库。

数据库优化

SQL 优化方向：

  • 执行计划
  • 索引
  • SQL 改写

架构优化方向：

  • 高可用架构
  • 高性能架构
  • 分库分表

数据库参数优化

①调整

实例整体(高级优化，扩展)：

thread_concurrency：# 并发线程数量个数 
sort_buffer_size：# 排序缓存 
read_buffer_size：# 顺序读取缓存 
read_rnd_buffer_size：# 随机读取缓存 
key_buffer_size：# 索引缓存 
thread_cache_size：# (1G—>8, 2G—>16, 3G—>32, >3G—>64)

②连接层(基础优化)

设置合理的连接客户和连接方式：

max_connections # 最大连接数，看交易笔数设置 
max_connect_errors # 最大错误连接数，能大则大 
connect_timeout # 连接超时 
max_user_connections # 最大用户连接数 
skip-name-resolve # 跳过域名解析 
wait_timeout # 等待超时 
back_log # 可以在堆栈中的连接数量

③SQL 层(基础优化)

query_cache_size： 查询缓存 >>> OLAP 类型数据库，需要重点加大此内存缓存，但是一般不会超过 GB。

对于经常被修改的数据，缓存会马上失效。我们可以使用内存数据库(redis、memecache)，替代它的功能。

存储引擎层优化

innodb 基础优化参数：

default-storage-engine 
innodb_buffer_pool_size # 没有固定大小，50%测试值，看看情况再微调。但是尽量设置不要超过物理内存70% 
innodb_file_per_table=(1,0) 
innodb_flush_log_at_trx_commit=(0,1,2) # 1是最安全的，0是性能最高，2折中 
binlog_sync 
Innodb_flush_method=(O_DIRECT, fdatasync) 
innodb_log_buffer_size # 100M以下 
innodb_log_file_size # 100M 以下 
innodb_log_files_in_group # 5个成员以下,一般2-3个够用（iblogfile0-N） 
innodb_max_dirty_pages_pct # 达到百分之75的时候刷写 内存脏页到磁盘。 
log_bin 
max_binlog_cache_size # 可以不设置 
max_binlog_size # 可以不设置 
innodb_additional_mem_pool_size #小于2G内存的机器，推荐值是20M。32G内存以上100M

参考文章：

https://www.cnblogs.com/zishengY/p/6892345.html

https://www.jianshu.com/p/d7665192aaaf

 

原链接https://www.toutiao.com/a6647024189007987208/

以上是关于超详细MySQL数据库优化的主要内容，如果未能解决你的问题，请参考以下文章

一份超详细的MySQL高性能优化实战总结！

超详细汇总21个mysql优化实践收藏版MySQL优化

MySQL优化从执行计划开始(explain超详细)

MySQL优化从执行计划开始(explain超详细)

超详细图解！MySQL进阶篇SQL优化-索引-存储引擎

数据库优化超详解！Linux上 MySQL 优化三板斧