1. MySQL适用的场景是什么？
数据量建议单实例T级或以内，不依赖存储过程、函数、触发器的传统oltp场景都适用，因为是一个相对轻量级的数据库
灾备使用MySQL各类的高可用方案即可，比如主从、mha、mgr等。
2. MySQL巡检应该怎么做？优先关注哪些参数？
可以从以下几个方面去做：
-
服务器配置
-
操作系统配置及重要参数
-
MySQL层配置及重要参数
-
MySQL对象
-
MySQL运行时的重要状态（日志、锁）
3. MySQL如何排查CPU占用高的问题？
重点是关于通过哪些系统表或者常用的sql来确定导致问题的sql？
方案一：通过pidstat命令定位
[root@localhost ~]# ps -ef | grep mysqld
mysql 5730 1 0 09:27 ? 00:00:18 /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf
root 14821 5810 0 14:38 pts/1 00:00:00 grep --color=auto mysqld
[root@localhost ~]# pidstat -t -p 5730
Linux 4.18.0-372.9.1.el8.x86_64 (localhost.localdomain) 2024年12月31日 _x86_64_ (1 CPU)14时38分14秒 UID TGID TID %usr %system %guest %wait %CPU CPU Command
14时38分14秒 27 5730 - 0.03 0.07 0.00 0.00 0.10 0 mysqld
14时38分14秒 27 - 5730 0.00 0.01 0.00 0.00 0.01 0 |__mysqld
14时38分14秒 27 - 5733 0.00 0.00 0.00 0.00 0.00 0 |__mysqld
14时38分14秒 27 - 5734 0.00 0.00 0.00 0.00 0.00 0 |__mysqld登录mysql，执行以下命令
mysql> select * from performance_schema.threads where thread_os_id = 5730;定位到具体sql接下来就可以分析优化了。
方案二：通过TOP命令定位
-
首先执行TOP命令，输入H，可以按照显示线程状态。
-
输入P，可以按照cpu的使用时间份额进行排序，这时候我们就可以看下是否有超过70%-90%以上的线程了。
登录mysql，执行以下命令
mysql> select * from performance_schema.threads where thread_os_id = 5730 \G
*************************** 1. row ***************************THREAD_ID: 1NAME: thread/sql/mainTYPE: BACKGROUNDPROCESSLIST_ID: NULLPROCESSLIST_USER: NULLPROCESSLIST_HOST: NULLPROCESSLIST_DB: mysql
PROCESSLIST_COMMAND: NULLPROCESSLIST_TIME: 18860PROCESSLIST_STATE: NULLPROCESSLIST_INFO: NULLPARENT_THREAD_ID: NULLROLE: NULLINSTRUMENTED: YESHISTORY: YESCONNECTION_TYPE: NULLTHREAD_OS_ID: 5730RESOURCE_GROUP: SYS_default
1 row in set (0.00 sec)4. MySQL数据库内存使用率高，应该如何进行排查？
Mysql Server Memory Usage= Sum of Global Buffers + (number of Connection * Per thread memory variables)
单个mysql连接线程的内存消耗统计，这里只是统计分配值（具体驻留内存占用值统计不到）
SELECT b.thread_id AS thd_id, b.user, a.current_count_used, a.current_allocated, a.current_avg_alloc, a.current_max_alloc, a.total_allocated, NULL AS current_statement
FROM performance_schema.memory_summary_by_thread_by_event_name a
JOIN performance_schema.sessions b
ON a.thread_id = b.thread_id
WHERE-- 可选的过滤条件，例如按用户或事件名称过滤-- b.user = 'your_username'-- AND a.event_name LIKE 'memory/%'
LIMIT 1; -- 如果您想要多个结果，请移除或调整此 LIMIT 子句统计 top 10 的buffer pool占用内存的表（在sys库中）
SELECT * FROM
innodb_buffer_stats_by_table
ORDER BY pages DESC LIMIT 10;5. MySQL数据库磁盘IO使用高，请问如何进行排查？
IO的话，可以查看这张表：performance_schema.file_instances：列出了文件I / O操作及其相关文件的工具实例
排查思路：
- 慢SQL排除
- 硬件问题-RAID降级，磁盘故障等排除
- innodb_log、innodb_buffer_pool_wait相关配置和等待
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。