MySQL 优化 (一)

优化风险

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

稳定性和业务可持续性通常比性能更重要！
优化不可避免涉及到变更，变更就有风险！
优化使性能变好，维持和变差是等概率事件！
优化不能只是数据库管理员担当风险，但会所有的人分享优化成果！
所以优化工作是由业务需要驱使的！！！

优化方向

安全优化（业务持续性）
性能优化（业务高效性）

优化的范围及思路

优化范围：
存储、主机和操作系统:
    主机架构稳定性
    I/O规划及配置
    Swap
    OS内核参数
        网络问题
应用程序:（Index，lock，session）
        应用程序稳定性和性能
        SQL语句性能
    串行访问资源
    性能欠佳会话管理
数据库优化:（内存、数据库设计、参数）
    内存
    数据库结构(物理&逻辑)
    实例配置

优化效果和成本的评估

Swap 问题

# Linux 7操作系统
# 内存使用达到100%-30%（70%）时候，才会时候swap
cat /proc/sys/vm/swappiness 
30  

# 修改不使用 swap
echo 0 >/proc/sys/vm/swappiness    的内容改成0（临时）

vi /etc/sysctl.conf
# 添加:
vm.swappiness=0

# 使配置生效
sysctl -p 

这个参数决定了Linux是倾向于使用swap，还是倾向于释放文件系统cache。在内存紧张的情况下，数值越低越倾向于释放文件系统cache。
当然，这个参数只能减少使用swap的概率，并不能避免Linux使用swap。

修改MySQL的配置参数innodb_flush_method，开启O_DIRECT模式
这种情况下，InnoDB的buffer pool会直接绕过文件系统cache来访问磁盘，但是redo log依旧会使用文件系统cache。
值得注意的是，Redo log是覆写模式的，即使使用了文件系统的cache，也不会占用太多

IO 问题

[root@localhost ~]# iostat -xz 1
Linux 3.10.0-693.el7.x86_64 (localhost.localdomain)     08/29/2019      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.02    0.00    0.05    0.00    0.11   99.81

Device:    rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda        0.00     0.01    0.78    0.10     2.21     0.70     6.59     0.00    0.36    0.20    1.54   0.14   0.01
dm-0        0.00     0.00    0.18    0.09     0.47     0.69     8.68     0.00    0.94    0.46    1.94   0.17   0.00
dm-1        0.00     0.00    0.17    0.00     0.67     0.00     8.02     0.00    0.08    0.08    0.00   0.08   0.00
# 现象说明
1. IO 高 cpu us 也高, 属于正常现象
2. CPU  us高  IO很低, MySQL 不在做增删改查,有可能是存储过程,函数,排序,分组,多表连接
3. Wait,SYS 高, IO低: IO出问题了,锁等待过多的几率比较大. 
IOPS：每秒磁盘最多能够发生的IO次数，这是个定值。 频繁小事务,IOPS很高,达到阈值,可能IO吞吐量没超过IO最大吞吐量.无法新的IO了，存储规划有问题.

MySQL 优化 (一)

标签：出现   code   nic   技术   x86_64   图片   使用   mysql 优化   %s