DevOps开发运维
成长之路

MySQL优化思路分解

优化思路

1.硬件层面->系统OS->文件系统FS->Mysql示例->逻辑结构->SQL,索引,锁->架构
2.MySQL实例:每个参数都对应一个状态variables->status
3.逻辑结构:schema设计:库表设计规范,DDL操作
4.语句优化
a.索引优化:优化DQL
b.锁排查:
SQL语句改写:
5.架构:高可用(MHA,PXC),高性能(读写分离,分布式架构)

硬件优化

主机

真实的硬件(PC Server): DELL R系列 ,华为,浪潮,HP,联想
云产品:ECS、数据库RDS、DRDS
IBM 小型机 P6 570 595 P7 720 750 780 P8

CPU根据数据库类型

【OLTP】
IO密集型: E系列(至强),主频相对低,核心数量多
IO密集型:线上系统,OLTP主要是IO密集型的业务,高并发
【OLAP】
CPU密集型:数据分析数据处理,OLAP,cpu密集型的,需要CPU高计算能力(i系列,IBM power系列)
CPU密集型: I 系列的,主频很高,核心少 
【内存】
建议2-3倍cpu核心数量 (ECC)
【磁盘选择】
SATA-III SAS(900G) Fc SSD(sata) pci-e ssd Flash
主机 RAID卡的BBU(Battery Backup Unit)关闭
【存储】
根据存储数据种类的不同,选择不同的存储设备
配置合理的RAID级别(raid5、raid10、热备盘) 
r0 :条带化 ,性能高
r1 :镜像,安全,主要操作系统使用
r5 :校验+条带化(浪费1/3磁盘),安全较高+性能较高(读),写性能较低 (适合于读多写少)
r10:安全+性能都很高,最少四块盘,浪费一半的空间(高IO要求)
【网络】
1、硬件买好的(单卡单口)
2、网卡绑定(bonding),交换机堆叠
以上问题,提前规避掉。

操作系统优化

Swap调整

echo 0 >/proc/sys/vm/swappiness的内容改成0(临时),
/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调度策略

centos 7 默认是deadline
cat /sys/block/sda/queue/scheduler
--------------------------------------
#临时修改为deadline(centos6)
echo deadline >/sys/block/sda/queue/scheduler 
vi /boot/grub/grub.conf
更改到如下内容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet
--------------------------------------
IO :
raid
no lvm
ext4或xfs
ssd
IO调度策略
提前规划好以上所有问题,减轻MySQL优化的难度。

应用端

1. 开发过程规范,标准
2. 减少烂SQL:不走索引,复杂逻辑,切割大事务.
3. 避免业务逻辑错误,避免锁争用.
这个阶段,需要我们DBA深入业务,或者要和开发人员\业务人员配合实现
赞(1)

评论 抢沙发

评论前必须登录!

 

LNMP社群 不仅仅是技术

关于我们网站地图