数据库层面问题解决思路

数据库层面问题解决思路

一般应急调优的思路：

针对突然的业务办理卡顿，无法进行正常的业务处理！需要立马解决的场景！

1、show processlist

2、**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;

 3、通过执行计划判断，索引问题 (有没有、合不合理) 或者语句本身问题

 4、show status like ‘% lock%’; # 查询锁状态 kill SESSION_ID; # 杀掉有问题的 session 

常规调优思路：

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

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

系统层面

cpu 方面：

vmstat、sar top、htop、nmon、mpstat

内存：

free 、ps -aux 、

IO 设备 (磁盘、网络)：

iostat 、 ss 、 netstat 、 iptraf、iftop、lsof、

系统层面问题解决办法

你认为到底负载高好，还是低好呢？

在实际的生产中，一般认为 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 存在问题

基础优化

优化思路

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

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

1. 硬件优化

主机方面：

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

平衡内存和磁盘资源

随机的 I/O 和顺序的 I/O

主机 RAID 卡的 BBU (Battery Backup Unit) 关闭

cpu 的选择：

cpu 的两个关键因素：核数、主频

根据不同的业务类型进行选择：

cpu 密集型：计算比较多，OLTP 主频很高的 cpu、核数还要多

IO 密集型：查询比较，OLAP 核数要多，主频不一定高的

内存的选择：

OLAP 类型数据库，需要更多内存，和数据获取量级有关。

OLTP 类型数据一般内存是 cpu 核心数量的 2 倍到 4 倍，没有最佳实践。

存储方面：

根据存储数据种类的不同，选择不同的存储设备

配置合理的 RAID 级别 (raid 5、raid 10、热备盘)

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

raid 卡：主机 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 分区)
• 这个参数决定了 Linux 是倾向于使用 swap，还是倾向于释放文件系统 cache。在内存紧张的情况下，数值越低越倾向于释放文件系统 cache。当然，这个参数只能减少使用 swap 的概率，并不能避免 Linux 使用 swap。
• 修改 MySQL 的配置参数 innodb_flush_method，开启 O_DIRECT 模式。这种情况下，InnoDB 的 buffer pool 会直接绕过文件系统 cache 来访问磁盘，但是 redo log 依旧会使用文件系统 cache。值得注意的是，Redo log 是覆写模式的，即使使用了文件系统的 cache，也不会占用太多

应用优化

业务应用和数据库应用独立，防火墙：iptables、selinux 等其他无用服务 (关闭)：

安装图形界面的服务器不要启动图形界面 runlevel 3, 另外，思考将来我们的业务是否真的需要 MySQL，还是使用其他种类的数据库。用数据库的最高境界就是不用数据库。

数据库优化

SQL 优化方向：

执行计划、索引、SQL 改写

架构优化方向：

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