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_statement
FROM memory_by_thread_by_current_bytes a, session b
WHERE a.thread_id = b.thd_id
LIMIT 1;

统计 top 10 的buffer pool占用内存的表

SELECT * 
FROM 
innodb_buffer_stats_by_table 
ORDER BY pages DESC
LIMIT 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。