1.1 优化哲学
² 优化不总是对一个单纯的环境进行！还很可能是一个复杂的已投产的系统。
² •优化手段本来就有很大的风险，只不过你没能力意识到和预见到！
² •任何的技术可以解决一个问题，但必然存在带来一个问题的风险！
² •对于优化来说解决问题而带来的问题控制在可接受的范围内才是有成果。
² •保持现状或出现更差的情况都是失败！
² 稳定性和业务可持续性通常比性能更重要！
² 优化不可避免涉及到变更，变更就有风险！
² 优化使性能变好，维持和变差是等概率事件！
² 优化不能只是数据库管理员担当风险，但会所有的人分享优化成果！
² 所以优化工作是由业务需要驱使的！！！
谁参与优化？
² 数据库管理员
² 业务部门代表
² 应用程序架构师
² 应用程序设计人员
² 应用程序开发人员
² 硬件及系统管理员
² 存储管理员
1.2 优化方向
1. 优化角度：
² 稳定性优化（业务持续性）
² 性能优化（业务高效性）
2. 优化范围
存储、主机和操作系统:
² 主机架构稳定性
² I/O规划及配置
² Swap
² OS内核参数和网络问题
应用程序:
² 应用程序稳定性
² SQL语句性能
² 串行访问资源
² 性能欠佳会话管理
² 这个应用适不适合用MySQL
数据库优化:
² 内存
² 数据库结构(物理&逻辑)
² 实例配置
不管是设计系统，定位问题，优化问题都可以安装这个顺序执行
1.3 数据库优化思路
优化维度：
硬件（主机、存储、网络设备）----->操作系统------>应用层---->数据库层（数据库实例----->逻辑结构）------>SQL
² 数据库优化维度有四个:硬件、系统配置、数据库表结构、SQL及索引
² 优化成本:硬件、系统配置、数据库表结构、SQL及索引
² 优化效果:硬件、系统配置、数据库表结构、SQL及索引
1.1 优化工具
硬件：
1.状态灯：一般状态绿灯，故障红灯，还有网络设备的橙色灯
2.自带管理设备：远程控制卡（FENCE设备：ipmi ilo idarc），开关机，硬件监控。
3.第三方监控设备、设备（snmp、agent）
4. 存储设备：自带的监控平台.EMC2（惠普收购了），日立（hds），IBM低端OEM hds的，
ds8000系列（机头是2台小型机 p6 570）
操作系统：
top, sar, iostat、vmstat、nmon
CPU：以时间为维度
IO
MEM
1.1.1 vmstat介绍
Procs（进程）
r: 运行队列中进程数量，这个值也可以判断是否需要增加CPU。（长期大于1）
b: 等待IO的进程数量。
Memory（内存）
swpd: 使用虚拟内存大小，如果swpd的值不为0，但是SI，SO的值长期为0，这种情况不会影响系统性能。
free: 空闲物理内存大小。
buff: 用作缓冲的内存大小。
cache: 用作缓存的内存大小，如果cache的值大的时候，说明cache处的文件数多，如果频繁访问到的文件都能被cache处，那么磁盘的读IO bi会非常小。
Swap
si: 每秒从交换区写到内存的大小，由磁盘调入内存。
so: 每秒写入交换区的内存大小，由内存调入磁盘。
注意：内存够用的时候，这2个值都是0，如果这2个值长期大于0时，系统性能会受到影响，磁盘IO和CPU资源都会被消耗。有些朋友看到空闲内存（free）很少的或接近于0时，就认为内存不够用了，不能光看这一点，还要结合si和so，如果free很少，但是si和so也很少（大多时候是0），那么不用担心，系统性能这时不会受到影响的。
IO（现在的Linux版本块的大小为1kb）
bi: 每秒读取的块数
bo: 每秒写入的块数
注意：随机磁盘读写的时候，这2个值越大（如超出1024k)，能看到CPU在IO等待的值也会越大。
system（系统）
in: 每秒中断数，包括时钟中断。
cs: 每秒上下文切换数。
注意：上面2个值越大，会看到由内核消耗的CPU时间会越大。
CPU（以百分比表示）
us: 用户进程执行时间百分比(user time)
us的值比较高时，说明用户进程消耗的CPU时间多，但是如果长期超50%的使用，那么我们就该考虑优化程序算法或者进行加速。
sy: 内核系统进程执行时间百分比(system time)
sy的值高时，说明系统内核消耗的CPU资源多，这并不是良性表现，我们应该检查原因。
wa: IO等待时间百分比
wa的值高时，说明IO等待比较严重，这可能由于磁盘大量作随机访问造成，也有可能磁盘出现瓶颈（块操作）。
id: 空闲时间百分比
1.1.2 iostat介绍
[root@db02 ~]# iostat -dk 1 5
Linux 2.6.32-696.el6.x86_64 (db02) 11/28/2017 _x86_64_ (1 CPU)
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
scd0 0.02 0.08 0.00 132 0
sda 3.77 123.15 8.64 194958 13670
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
scd0 0.00 0.00 0.00 0 0
sda 1.00 8.00 0.00 8 0
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
scd0 0.00 0.00 0.00 0 0
sda 0.00 0.00 0.00 0 0
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
scd0 0.00 0.00 0.00 0 0
sda 0.00 0.00 0.00 0 0
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
scd0 0.00 0.00 0.00 0 0
sda 0.00 0.00 0.00 0 0
[root@db02 ~]#
tps：该设备每秒的传输次数。一次I/O请求。多个逻辑请求可能会被合并为一次I/O请求
iops：硬件出厂的时候，厂家定义的一个每秒最大的IO次数。
“一次传输”请求的大小是位置的
kB_read/s ：每秒从设备读取的数据量
kB_wrtn/s ： 每秒向设备写入的数据量
kB_read ：读取的总数据量
kB_wrtn：写入的总数据量（单位为kilobytes）
【案例】cpu高 IO量低
CPU很繁忙但IO很空闲
原因分析：
IO出问题了（磁盘到临界了、raid设计不好。raid降级、锁、在单位时间内tps过高）
tps过高：大量的小数据IO、大量的全表扫描
1.1.3 数据库
基础优化命令工具
² mysql
² SHOW [SESSION | GLOBAL] STATUS
² SHOW ENGINE INNODB STATUS
² SHOW PROCESSLIST
² show index
² Information Schema
² mysqldumpslow
² explain
² msyqladmin
² mysqlshow
深度优化命令工具（扩展）
² mysqlslap
² sysbench
² mysqlprofiling
² Performance Schema
1.2 企业基础优化实战
1、思路：
定位问题：
² 硬件
² 系统
² 应用
² 数据库
² 架构（高可用、读写分离、分库分表）
处理问题
² 明确优化目标
² 性能和安全的折中
² 防患未然
最高境界是：防患于未然，避免安全问题出现，尽量做到主动优化，避免被动优化
2、硬件优化：
主机：
² 根据数据库类型，主机CPU选择、内存容量选择、磁盘选择
n CPU的选择：CPU的两个关键因素：核数，主频主要看业务类型
业务类型：cpu密集型（以计算为主，OLTP在线业务处理系统）、io密集型（查询比较多的，OLAP）.
内存的选择：
OLAP类型数据库，需要更多的内存，和数据获取量级有关。
OLTP类型数据库，一般内存是cpu核心数量的2倍到4倍，没有最佳实践。
IO设备选择
硬盘：对于操作系统来讲，不需要太特殊的选择，但是最好做好冗余
raid卡：主机raid卡，实现了操作系统磁盘的冗余（raid1）热备盘
² 平衡内存和磁盘资源
配置大量内存原因其实不是因为可以在内存中保存大量的数据而最终目的的避免磁盘IO。当所有数据放到内存中，此时服务器热起来，所有的数据读取操作都会缓存命中，换句话说，缓存可以延迟写入，此时便会出现缓存命中率，可以使用CPU利用率来判断缓存命中。
² 随机的I/O和顺序的I/O
顺序IO的执行速度比随机IO操作的快，无论在内存好事磁盘，所以增加内存是解决问题的最好方法，如果有足够的内存，就可以完全避免磁盘的读取请求，存储引擎的顺序读取比随机读取快。
² 主机RAID卡的BBU(Battery Backup Unit)关闭
存储：
² 根据存储数据种类的不同，选择不同的存储设备
² 配置合理的RAID级别(raid5、raid10、热备盘)
raid 10 4块盘
raid5 3块盘---特别怕坏，坏了热备盘都救不了。
网络设备：
² 使用流量支持更高的网络设备（交换机、路由器、网线、网卡、HBA卡）
注意：这些规划应该在初始设计系统时就应该考虑好
3、系统优化
Cpu：
² 基本不需要调整，在硬件选择方面下功夫即可。
内存：
² 基本不需要调整，在硬件选择方面下功夫即可。
SWAP：
² MySQL尽量避免使用swap。
IO：
² raid
² no lvm
² ext4或xfs
² ssd
² IO调度策略
4、Linux系统内核参数优化
/etc/sysctl.conf
net.ipv4.ip_local_port_range=102465535
net.ipv4.tcp_max_syn_backlog=4096
net.ipv4.tcp_fin_timeout=30
fs.file-max=65535------------>最大文件句柄，控制的是能打开文件的最大数量（是全局的）
5、用户限制参数（mysql可以不设置）
/etc/security/limits.conf
* soft nproc65535 #最大的进程数量
* hard nproc65535
* soft nofile65535
* hard nofile65535
6、应用优化
² 业务应用和数据库应用独立
² 防火墙：iptablesselinux
其他(关闭无用服务)：
chkconfig--level 23456 acpidoff
chkconfig--level 23456 anacronoff
chkconfig--level 23456 autofsoff
chkconfig--level 23456 avahi-daemon off
chkconfig--level 23456 bluetoothoff
chkconfig--level 23456 cups off
chkconfig--level 23456 firstbootoff
chkconfig--level 23456 haldaemonoff
chkconfig--level 23456 hplipoff
chkconfig--level 23456 ip6tables off
chkconfig--level 23456 iptablesoff
chkconfig--level 23456 isdn off
chkconfig--level 23456 pcscdoff
chkconfig--level 23456 sendmailoff
chkconfig--level 23456 yum-updatesdoff
7、数据库优化
参数调整：
实例整体（高级优化，扩展）：
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，memcached）替代它的功能。
存储引擎层（innodb基础优化参数）
default-storage-engine
innodb_buffer_pool_size*********内存缓冲值（缓冲即读又写），没有固定大小只有阀值，但是 尽量设置不要超过物理内存的70%
innodb_file_per_table=(1,0)
innodb_flush_log_at_trx_commit=(0,1,2)#redolog，1：每一次commit都必须要刷新到磁盘（最安全），0：每一秒钟刷新到磁盘（性能最高），2：折中
Innodb_flush_method=(O_DIRECT, fdatasync)
innodb_log_buffer_size 100M以下
innodb_log_file_size 5个成员以下
innodb_log_files_in_group
innodb_max_dirty_pages_pct
log_bin
max_binlog_cache_size 尽可能小点
max_binlog_size 尽量小点（可以不设置）
innodb_additional_mem_pool_size(于2G内存的机器，推荐值是20M。32G内存的100M)缓存元数据
transaction_isolation#隔离级别默认就是这个
8、数据库优化
SQL优化：
² 执行计划（基础优化）
² 索引（基础优化）
² SQL改写（高级优化）
架构优化（高级优化扩展）：
² 高可用架构
² 高性能架构
² 分库分表；