MySQL DBA需要掌握的 7 个问题
1、MySQL适用的场景是什么？
数据量建议单实例T级或以内，不依赖存储过程、函数、触发器的传统oltp场景都适用，因为是一个相对轻量级的数据库
灾备使用MySQL各类的高可用方案即可，比如主从、mha、mgr等。
2、MySQL巡检应该怎么做？优先关注哪些参数？
可以从以下几个方面去做：
- 服务器配置
- 操作系统配置及重要参数
- MySQL层配置及重要参数
- MySQL对象
- MySQL运行时的重要状态（日志、锁）
3、MySQL如何排查CPU占用高的问题？
重点是关于通过哪些系统表或者常用的sql来确定导致问题的sql？
方案一、通过pidstat命令定位
首先我们先找到mysqld进程的PID，然后执行pidstat -t -p $PID，结果如下图：
进入mysql交互命令，通过以下命令查询具体SQL。
select * from performance_schema.threads where thread_os_id = '1';
定位到了具体定位sql接下来就可以分析优化了。
方案二、通过TOP命令定位
- 首先执行TOP命令，输入H，可以按照显示线程状态。
- 输入P，可以按照cpu的使用时间份额进行排序，这时候我们就可以看下是否有超过70%-90%以上的线程了。
登录mysql，执行以下命令
select * from performance_schema.threads where THREAD_OS_ID=4461 \G
4、MySQL数据库内存使用率高，应该如何进行排查？
Mysql Server Memory Usage= Sum of Global Buffers + (number of Connection * Per thread memory variables)
单个mysql连接线程的内存消耗统计，这里只是统计分配值（具体驻留内存占用值统计不到）
SELECT b.thd_id, b.user, current_count_used, current_allocated, current_avg_alloc , current_max_alloc, total_allocated, current_statementFROM memory_by_thread_by_current_bytes a, session bWHERE a.thread_id = b.thd_idLIMIT 1;
统计 top 10 的buffer pool占用内存的表
SELECT * FROM innodb_buffer_stats_by_table ORDER BY pages DESCLIMIT 10;
5、MySQL数据库磁盘IO使用高，请问如何进行排查？
mysql5.7版本为例，结合performance_schema来查看MySQL数据库的各种指标。相当于Oracle数据库中的各种性能视图，可以查看几乎所有的数据库状态。
IO的话，可以查看这张表：
performance_schema.file_instances：列出了文件I / O操作及其相关文件的工具实例
排查思路：
1、慢SQL排除
2、硬件问题-RAID降级，磁盘故障等排除
2、innodb_log、innodb_buffer_pool_wait相关配置和等待
3、IO相关参数配置
innodb_flush_method = O_DIRECT
innodb_file_per_table = 1
innodb_doublewrite = 1
delay_key_write
innodb_read_io_threads
innodb_read_io_threads
innodb_io_capacity
innodb_flush_neighbors
sync_binlog
对比历史性能记录，结合业务以及负载来分析。
6、有哪些工具可以帮助优化MySQL的？
以下工具可以参考：
pt-mysql-summary
pt-variable-advisor
pt-duplicate-key-checker
pt-deadlock-logger
或者
tuning-primer.sh
https://github.com/major/MySQLTuner-perl
7、目前主流的MySQL高可用采用哪种方式，MHA还是MGR？
由于MGR技术相对较新，目前使用MHA更多。但个人认为，MGR或者基于此的innodb cluster架构（或替代方案）会成为未来主流。
MHA：
优点：成熟稳定，自动切换主从，主节点宕机后尽可能少丢失数据（自动抓取未复制的binlog）。
缺点：管理节点单点、可能脑裂、可能有不必要切换、还是有丢数据风险、组件多维护相对麻烦
MGR：
优点：基于paxos的高可用架构，支持多主（不建议），强一致
缺点：需要innodb引擎（丢业务有改造代价），应用端没有自动切换（可以通过中间件解决），技术太新可能有未知bug。