MySQL整体思路
培养框架思想。此章不涉及高可用。迎战明天 有缘网 面试
问题发现：ping traceroute nslookup telnet
思想：把用户一些的请求，往前推。
app层
有多少JDOC连接后端DB，进程池是多少，DB发现大量连接数解决。
硬件层
磁盘；I/O 性能，主要出现瓶颈；事务日志刷磁盘方式；
内存 buffer；
CPU 引擎限制；
网络层
replication等基于网络传输。
主节点，让一个库 不同步到从库：解决方案2种：
主库调整，节省I/O，速度快。
从库调整，binlog会传输到从库，但耗费带宽。
监控最好方法：主库写入，从库查询是否存在。
双网卡绑定做bond
iftop cacti zabbix 发送 接送 流量 即使发现网络瓶颈
系统层
ulimit 最大使用进程
系统的timewait超时时间
系统连接数对比 检查
snmpwalk 确认snmp正常，监控是否正常
远程连接端口更改
chattr 对关键文件加锁
linux进程理论最大数：4090 LDT GDT
iostat 监控磁盘I/O，即使发现DB 出现的I/O瓶颈
tcpdump 抓取数据包协议栈进行分析 nmap主机存活分析
DB层
三个层级：连接层；SQL层；存储层
Schema设计动态表，静态化
常规日常：检查数据量大小；索引；慢查询；
engine存储引擎状态分析
确认瓶颈： show log;
show global status;
show processlist;
show engine indoor status;
pt-ioprofile;
配置优化：innodb_buffer_pool_size;
innodb_data_file_path;
innodb_flush_log_at_trx_commit;
innodb_log_buffer_size;
innodb_log_file_size;
transaction_isolation;
MVCC并发控制中：读操作分为两类：快照读（snapshot read）与当前读(current read)
配置优化：其他
general_log （尽量不要打开），把每个语句都记录下来。
log_bin ：打开但是会影响性能，但是不得不打开。
sync_binlog：事务一致性:0最不安全 1每个事务刷binlog
long_query_time ：慢查询，0.01秒
log_slow_query ：后期分析 哪些慢查询最多的
以下内容列入web监控列表，对增长量进行绘图。
SQL上线进行记录，带来数值不准确 可有依据查询
show global status like 'Innodb_buffer_pool_pages_dirty'; #当前的脏页数
show global status like 'Handler_rollback'; #内部ROLLBACK语句的数量。
show global status like 'Handler_write'; #在表内插入一行的请求数。
show global status like 'Handler_update'; #在表内更新一行的请求数
show global status like 'Innodb_buffer_pool_pages_total'; #缓冲池总大小（页数）
show global status like 'Innodb_data_reads'; #数据读总数量。
show global status like 'Innodb_data_writes'; #数据写总数量。
show global status like 'Innodb_data_written'; #至此已经写入的数据量（字节)
show global status like 'Innodb_log_write_requests'; #日志写请求数。
show global status like 'Innodb_log_writes'; #向日志文件的物理写数量
show global status like 'Open_tables'; #当前打开的表的数量。
本文出自 “晴空” 博客，谢绝转载！