mysql巡检做些什么

1.系统层面

如果有监控系统（比如zabbix、Prometheus等），可查看监控历史曲线，否则只能通过shell查看当前使用率
查看监控，主要留意 warning 或以上级别的告警，监控基本上可以覆盖 95% 以上的日常巡检需求

1.1.CPU

严重程度：★★★★★
问题描述：通过监控找到cpu平均使用率 > 80% 的实例，进一步分析是否慢查询导致的cpu飙升，或者cpu配置过低所致
检查方法：查看监控曲线（若有），或执行如下命令

top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1"%"}'

影响范围：如下表示

服务器ip	环境	cpu总核数	平均使用率
x.x.x.x	uat	32	16.03%
x.x.x.x	prod	32	21.84%

1.2.内存

严重程度：★★★★★
问题描述：通过监控找到内存平均使用率 > 80% 的实例，检查是否有内存不够用的问题，该扩容的扩容，防止OOM。若内存充裕而使用到 swap，大概率是由于未正确设置 numa 或 vm.swappiness 导致的
检查方法：查看监控曲线（若有），或执行 free -m
影响范围：如下表示

服务器ip	环境	内存总大小(GB)	平均使用率
x.x.x.x	uat	16	76.03%
x.x.x.x	prod	32	21.84%

1.3.磁盘

严重程度：★★★★★
问题描述：通过监控找到磁盘当前使用率 > 80% 的实例，节前巡检则关注使用率>70%的示例，提前扩容，避免长假期间发生告警
检查方法：查看监控曲线（若有），或执行 df -Th
影响范围：如下表示

服务器ip	环境	挂载点	磁盘总大小(GB)	剩余空间(GB)	可用空间率
x.x.x.x	uat	/	40	14.02	35.05%
x.x.x.x	prod	/data	200	43.68	21.84%

1.4.网络带宽

严重程度：★★★★★
问题描述：通常造成服务器带宽过高是由多种因素引起的，比如传输的数据量过大（比如查询结果集过大）、配置不当、网络攻击等
检查方法：查看监控曲线（若有）

2.可用性巡检

2.1.检查实例状态

严重程度：★★★★
问题描述：实例状态，一般来说就是检查 mysqld 的存活，有条件的话可以分析其是否健康
检查方法：执行如下sql查看服务运行信息

select @@innodb_version, @@port, @@datadir, now()-interval variable_value second as uptime 
from performance_schema.global_status where variable_name='uptime';

影响范围：如下表示

服务器ip	环境	mysql版本	服务端口	数据目录	运行时间
x.x.x.x	uat	5.7.42-45	3306	/var/lib/mysql/data/	2023-12-06 10:50
x.x.x.x	prod	5.7.42-45	3306	/var/lib/mysql/data/	2024-01-01 23:59

2.2.检查高可用架构有效性

严重程度：★★★★
问题描述：单实例部署无冗余，一旦实例故障将导致业务中断；主从同步延迟过高可能导致读写分离时数据不一致，影响业务准确性；故障切换失效或切换时长过长会扩大业务中断范围，增加损失
检查方法：检查是否采用主从架构（一主一从or一主多从）或集群架构（MGR集群），是否存在单实例部署（无冗余），通过巡检证明数据库是"可切换"状态

2.3.检查复制状态

严重程度：★★★★★
问题描述：检查主从同步的复制状态、容灾的DTS状态等，看是否正常，同步延迟正常应≤1秒
检查方法：在从库上执行 show slave status\G; 若 Slave_IO_Running 与 Slave_SQL_Running 均为 Yes 则判定同步无异常，若 Seconds_Behind_Master 为 0 则判定同步无延迟
影响范围：如下表示

主库ip	从库ip	同步类型	同步状态	备注
x.x.x.x	y.y.y.y	主主同步	正常or异常	xxx

2.4.检查VIP状态

严重程度：★★★★
问题描述：除了检查当前在用的VIP状态，如果有双网络冗余链路（即双VIP），还要有一个冗余vip的巡检机制，因为冗余vip故障对业务是没有感知的，可以定制一个定时的探测和告警任务
影响范围：若无vip则不适用

2.5.检查自增id上限

严重程度：★★★★★
问题描述：整数类型的字段能够保存的数值是有限的，超出最大值的数据无法写入表中，数值类型溢出会导致程序报错
检查方法：检查每张表的自增id是否即将达到最大值

SELECT a.table_schema, a.table_name, b.column_type, a.auto_increment 
FROM information_schema.tables a join information_schema.columns b on a.table_schema=b.table_schema and a.table_name=b.table_name 
WHERE b.extra='auto_increment' 
and (  (b.column_type like 'int%' and a.auto_increment > 1900000000) 
    or (b.column_type like 'bigint%' and a.auto_increment > 8000000000000000000) 
);

影响范围：如下表示

服务器ip	环境	库名	表名	字段类型	当前自增值	最大可用值
x.x.x.x	uat	db1	table	int	-	2147483647
x.x.x.x	prod	db2	table	bigint	-	9223372036854775807

2.6.检查连接失败率

严重程度：★★★★★
问题描述：MySQL连接失败率是一个重要的系统健康指标，通常用于监控数据库性能和可用性。通常，连接失败率 >5% 则建议立即处理
检查方法：连接失败率 = Aborted_connects / (Connections + Aborted_connects) * 100%

SELECT 
  Aborted_connects AS failure_conn_count, Connections AS success_conn_count,
  ROUND((Aborted_connects * 100.0 / (Connections + Aborted_connects)), 4) AS connection_failure_percent
FROM (
  SELECT 
    MAX(CASE WHEN variable_name = 'Aborted_connects' THEN variable_value END) AS Aborted_connects,
    MAX(CASE WHEN variable_name = 'Connections' THEN variable_value END) AS Connections
  FROM performance_schema.global_status WHERE variable_name IN ('Aborted_connects', 'Connections')
) AS stats;

3.可靠性巡检

3.1.检查实例资源配置是否合理

严重程度：★★★★★
问题描述：资源配置不足会导致数据库性能下降，出现查询延迟、事务阻塞等问题，影响用户体验；资源配置过高会造成成本浪费；磁盘空间不足会导致数据库无法写入数据、备份失败，甚至业务中断
检查方法：通过监控平台，查看近7天CPU利用率、内存使用率、磁盘IOPS、磁盘空间使用率，是否存在持续高负载（CPU≥80%、内存≥85%、IOPS≥90%阈值，持续10分钟以上）
处理方法：针对持续高负载，优先优化SQL和业务逻辑，若优化后仍高负载，升级实例规格

3.2.检查核心参数配置是否合理

严重程度：★★★★★
问题描述：参数配置不合理会导致数据库性能下降（如innodb_buffer_pool_size过小导致缓存命中率低）、资源浪费（如max_connections过大导致内存占用过高）、连接失败（如max_connections过小无法支撑高并发）、事务异常（如innodb_log_file_size过小导致日志切换频繁）
处理方法：基于实例规格和业务负载，优化关键参数配置
检查方法：重点关注与安全和性能有关的参数，包含并不仅限于以下这些：

# cat my.cnf | egrep "(timeout|lower|bin|expire|slave|gtid|query|log|max|innodb|infile|links)"

wait_timeout = 1500                 #.关闭非交互连接之前等待活动的秒数,默认28800秒(8h)
interactive_timeout = 1500          #.关闭交互式连接前等待活动的秒数,默认28800秒(8h)
connect_timeout = 60                #.连接超时时间
lower_case_table_names = x          #.是否开启大小写敏感,0区分/1不区分
log_bin = /path/mysql-bin           #.配置binlog日志路径,默认datadir
binlog_format = row                 #.设置binlog日志格式
binlog_row_image = full             #.默认full(在binlog为row格式下)会记录所有的行信息
expire_logs_days = x                #.超过x天的binlog删除
sync_binlog = 1                     #.刷binlog方式,直接影响性能和完整性,0高性能/1高安全
skip_slave_start = 1                #.禁用之后,slave进程会随着mysql启动而启动

gtid_mode = on                      #.是否开启gtid功能
enforce_gtid_consistency = on       #.强制gtid一致性

slow_query_log = 1                      #.是否启用慢查询,默认0不启用
long_query_time = 3                     #.慢查询阀值时间,默认超过10秒的查询才写日志
log_output = file                       #.默认FILE将日志存入文件,改为TABLE则写入系统表
slow_query_log_file = /path/slow.log    #.开启慢查询日志,记录查询过长的语句以便优化

max_connections = 3000                  #.所有用户同时打开的最大连接数,默认151
max_user_connections = 2000             #.每个用户同时打开的最大连接数
max_connect_errors = 10000              #.针对某个IP连接中断与mysql服务连接的次数

innodb_buffer_pool_size = 2g            #.保存索引和原始数据的缓冲池大小,建议为物理内存的50-60%,默认8M
innodb_log_file_size = 512M             #.日志文件的大小,更大的设置可以提高性能,但也会增加故障恢复所需的时间
innodb_flush_log_at_trx_commit = 1      #.log buffer刷新到磁盘的方式,默认1最安全,0性能最好,其他值则折衷
innodb_file_per_table = 1               #.设置innodb引擎独立表空间,建议启用

local_infile = 0                        #.设置为0可禁用客户端load data local infile
skip_symbolic_links = yes               #.禁用符号链接以防止各种安全风险

3.3.检查主备参数是否一致

严重程度：★★★★
问题描述：若从库的参数与主库不一致，一旦发生故障转移就会存在风险
检查方法：检查这个主要是避免主备切换后发生主从复制异常，包含并不仅限于以下这些：

# cat my.cnf | egrep "(server|slave|master|relay)"

server_id = 2313306                     #.主库与从库不可相同
slave_parallel_workers = 8              #.
slave_parallel_type = LOGICAL_CLOCK     #.
master_info_repository = TABLE          #.
relay_log_info_repository = TABLE       #.
relay_log_recovery = 1                  #.

3.4.检查运行参数与持久化配置是否一致

严重程度：★★★★
问题描述：在 5.7 及以前，mysql不支持参数持久化，修改参数通常都是分两步，比如先动态设置 set global innodb_buffer_pool_size=128G; 然后登陆服务器修改 my.cnf，如果忘记持久化到my.cnf，则mysql一旦发生crash就会导致 innodb_buffer_pool_size 被还原为默认值的128M，从而造成性能问题或数据丢失风险
检查方法：检查数据库运行参数(show global variables;)和配置文件(my.cnf)参数是否一致

4.安全性巡检

4.1.检查是否启用密码复杂度策略

严重程度：★★★★★
问题描述：建议启用账号密码复杂度策略（长度≥8位、含大小写字母+数字+特殊符号）及定期更换机制（是否每90天内更换）
检查方法：执行 show variables like 'validate_password%'; 主要看 validate_password_policy 存在且不是空值

SELECT PLUGIN_NAME,PLUGIN_STATUS,PLUGIN_LIBRARY FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%password%';
SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME LIKE 'validate_password%' ORDER BY VARIABLE_NAME;
show variables like 'validate_password_check_user_name';       #.是否检查密码包含用户名
show variables like 'validate_password_dictionary_file';       #.密码字典文件路径
show variables like 'validate_password_length';                #.密码最小长度
show variables like 'validate_password_mixed_case_count';      #.需要大小写字母数
show variables like 'validate_password_number_count';          #.需要数字个数
show variables like 'validate_password_policy';                #.密码策略等级,LOW/MEDIUM/STRONG
show variables like 'validate_password_special_char_count';    #.需要特殊字符数

show variables like 'default_password_lifetime';               #.设置密码有效时间,单位天,默认0不启用

4.2.检查具有super权限的账号

严重程度：★★★★★
问题描述：建议遵循“最小权限原则”回收超配权限，核心业务账号仅授予必要的DML/DDL权限，运维账号严格限制操作范围
检查方法：查询除root之外、是否存在超配的SUPER权限、ALL PRIVILEGES权限的账号

SELECT user,host,Super_priv,Grant_priv FROM mysql.user WHERE Super_priv='Y' and user not in('root','mysql.session');

4.3.检查账号的授权范围

严重程度：★★★★★
问题描述：建议清理冗余IP白名单，仅保留授权业务服务器、运维终端IP/网段，禁止全开放配置
检查方法：核查账号关联的IP白名单，是否存在非授权IP地址、网段冗余或过宽（如0.0.0.0/0全开放）

select user,host from mysql.user where host<>'localhost';

4.4.检查防火墙是否开启

严重程度：★★★★
问题描述：检查是否开启防火墙并配置ip访问控制策略

iptables -nL
systemctl status firewalld.service

4.5.检查空口令或弱口令的账号

严重程度：★★★★★
检查方法：借助mysql弱口令检测工具，检查空口令、弱口令的账号
影响范围：如下表示

ip地址	服务	端口	账户名	密码	版本
x.x.x.x	MySQL	3306	root	root	5.7.33
x.x.x.x	MySQL	3306	root	123456	8.0.32

4.6.检查备份策略的有效性

严重程度：★★★★
问题描述：未配置有效备份策略，一旦发生数据丢失（如误删除、病毒攻击）无法恢复
检查方法：检查是否有备份机制，建议配置自动备份（每日全量+增量备份），启用跨区域备份并保留时间≥90天，备份时间调整到业务低峰期（如凌晨2-4点）

4.7.备份文件的恢复测试

严重程度：★★★★
问题描述：备份文件不完整或恢复流程无效，将导致业务长时间中断，为了保证备份的有效性，建议对每个备份集执行恢复测试
检查方法：随机抽取1-2份备份文件，开展恢复测试，验证备份文件完整性、恢复流程有效性及恢复时长（核心业务恢复时长应≤1小时），建议定期恢复测试（每季度1次）

4.8.检查SSL传输加密是否开启

严重程度：★★★★
问题描述：未启用传输加密可能导致数据在传输过程中被窃听，存储未加密/敏感数据明文存储可能引发数据泄露事件，违反《数据安全法》《个人信息保护法》
建议方案：启用SSL/TLS传输加密，下载SSL根证书并配置到应用端，强制应用端配置SSL连接参数
检查方法：执行 show variables like 'have_ssl'; 若返回 YES 则表示已开启ssl连接，执行 show variables like 'require_secure_transport'; 若返回 ON 则表示已强制用户使用ssl连接

show variables where variable_name in ('have_ssl','require_secure_transport');

4.9.检查加密存储是否开启

严重程度：★★★★
问题描述：未启用传输加密可能导致数据在传输过程中被窃听，存储未加密/敏感数据明文存储可能引发数据泄露事件，违反《数据安全法》《个人信息保护法》，备份文件未加密可能导致备份数据泄露
建议方案：建议对敏感数据（如手机号、身份证号、银行卡号）采用加密存储（如AES加密）或脱敏处理，采用应用层加密或数据库透明加密（TDE）方案，配置备份文件加密，确保不存在敏感数据明文备份、备份文件未加密的情况
检查方法：通过SQL查询敏感字段存储格式验证

4.10.检查审计日志是否开启

严重程度：★★★★
问题描述：未开启审计日志无法追溯安全事件责任人，日志保留时间不足不满足合规审计要求，未配置安全告警可能导致安全事件发生后无法及时发现，扩大损失范围，建议开启审计日志，且日志保留时间≥90天（满足合规要求）
检查方法：执行 show variables like 'general_log'; 若返回 ON 则表示已开启审计日志，执行 show variables like 'general_log_file'; 返回的则是通用查询日志文件位置

show variables where variable_name in ('general_log','general_log_file','log_output');

5.性能巡检

5.1.关注 InnoDB 缓冲池命中率

严重程度：★★★★★
问题描述：高命中率意味着更多数据从内存读取，减少磁盘I/O，若缓存命中率过低则会导致系统响应缓慢，直接影响查询性能。通常，低于 95% 则需要开始关注，低于 70% 则性能已明显下降，需要立即优化

#.InnoDB缓冲池命中率 = 1 - (物理读 / 逻辑读)
SELECT ROUND( 
  (1 - (SELECT variable_value FROM performance_schema.global_status WHERE variable_name = 'Innodb_buffer_pool_reads') 
 /(SELECT variable_value FROM performance_schema.global_status WHERE variable_name = 'Innodb_buffer_pool_read_requests') ) * 100, 4 ) as hit_ratio;

5.2关注临时表的使用情况

严重程度：★★★★
问题描述：临时表的创建通常与排序、分组、联合等操作有关，当临时表的大小超过一定限制或者临时表中包含BLOB/TEXT列（这些类型不能存储在内存临时表中）时，临时表将在磁盘上创建。Created_tmp_disk_tables 记录了mysql创建的磁盘临时表数量（内存放不下时转存到磁盘），Created_tmp_tables 记录了mysql创建的所有临时表总数（包括内存和磁盘）。磁盘临时表的比例 = Created_tmp_disk_tables / Created_tmp_tables * 100%。如果发现临时表创建过多，可能需要优化查询，例如添加合适的索引，避免使用临时表。如果发现磁盘临时表的比例过高，可以考虑通过调整tmp_table_size和max_heap_table_size参数来适当增加内存临时表的最大大小（会占用更多的内存），从而减少磁盘临时表的创建。
检查方法：执行 show global status like 'Created_tmp%'; 查看指标。如果磁盘临时表比例超过 10% 则建议关注，超过 25% 则应该进行优化

5.3关注表锁的使用情况

严重程度：★★★★
问题描述：如下2个指标用于监控MySQL表级锁的争用情况，是评估并发性能的重要指标。Table_locks_immediate 表示立即获得表级锁的次数（请求锁时无需等待），该值越高则并发性能越好。Table_locks_waited 需要等待的表级锁的次数（请求锁需要等待其他会话释放锁），越高则锁竞争越严重。锁等待率 = Table_locks_waited / (Table_locks_immediate + Table_locks_waited)
检查方法：执行 show global status like 'table_locks%'; 查看指标。如果锁等待率低于0.1%则优秀，超过5%则建议进行优化，比如优化事务尽快提交、使用InnoDB（采用行级锁）、优化查询减少锁持有时间。

5.4关注Open table的使用情况

严重程度：★★★★
问题描述：Open_tables表示打开表的数量，Opened_tables表示打开过的表数量，如果Opened_tables增长很快，而Open_tables相对较小，可能意味着表缓存（table_open_cache）设置不足，导致频繁打开和关闭表。表缓存命中率 = 1 - (Opened_tables / (Open_tables + Opened_tables))
检查方法：执行 show global status like 'open%tables%'; 查看指标。如果命中率高于95%则表示优秀，低于85%则建议关注，低于70%则建议进行优化

5.5.关注 top 20 大库

严重程度：★★★★★
问题描述：单实例的数据库控制在20个以内、大小500G以内

select ist.table_schema
,round(sum(ist.data_length+ist.index_length)/1024/1024,2) as total_size_mb
,round(sum(ist.data_length)/1024/1024,2) as data_size_mb
,round(sum(ist.index_length)/1024/1024,2) as index_size_mb
,iss.default_character_set_name
,iss.default_collation_name
from information_schema.tables as ist
join information_schema.schemata as iss on ist.table_schema = iss.SCHEMA_NAME
where ist.table_schema not in ('information_schema','mysql','performance_schema','sys','percona_schema') 
group by ist.table_schema 
order by sum(ist.data_length+ist.index_length) desc limit 20;

5.6.关注 top 20 大表

严重程度：★★★★★
问题描述：大表在做全表扫描时非常耗费性能，执行DDL操作更是灾难，大于 100G 的表都应该评估一下，为什么这么大？是否可以迁到TiDB？是否可以归档或分库分表？
推荐建议：单表行数控制在1000w行以内、大小30G以内，针对单表超过1000w的大表，建议对历史数据进行清理或归档(改动小)、分表(推荐方案)

select table_schema,table_name,table_rows
,round(sum(DATA_LENGTH+INDEX_LENGTH)/1024/1024,2) as total_size_mb
,round(sum(DATA_LENGTH)/1024/1024,2) as data_size_mb
,round(sum(INDEX_LENGTH)/1024/1024,2) as index_size_mb 
from information_schema.tables 
where table_schema not in ('information_schema','mysql','performance_schema','sys','percona_schema') 
group by table_schema,table_name 
order by round(sum(DATA_LENGTH+INDEX_LENGTH)/1024/1024,2) desc limit 20;

5.7.关注 top 20 慢查询

严重程度：★★★★★
问题描述：慢查询过多会占用大量数据库资源（CPU、内存、IO），导致数据库性能下降，影响所有业务查询；大事务会导致锁等待时间过长，引发事务阻塞，甚至导致主从同步延迟加剧；死锁会导致事务无法正常执行，影响业务流程
处理方法：针对慢查询语句，优化SQL逻辑（如拆分复杂查询、避免全表扫描），添加合适的索引（如联合索引、覆盖索引），避免索引失效（如避免使用函数操作索引字段、模糊查询前缀通配符）；拆分大事务为小事务，减少事务执行时间，避免长时间占用锁资源
检查方法：启用慢查询日志功能，设置慢查询阈值（核心业务建议≤1秒），查看近7天慢查询日志，统计慢查询数量、高频慢查询语句

#.找出慢日志文件的位置
show variables where variable_name in ('log_output','slow_query_log_file'); 

#.查找最近7天的慢查询, 比如今天是 2026-01-24
grep -E "^(2026-01-0|2026-01-2)" mysql_slow.log | grep Query_time | more

#.Just take effect when log_output = table
SELECT start_time,user_host,query_time,lock_time,rows_sent,db FROM mysql.slow_log WHERE start_time > DATE_SUB(NOW(), INTERVAL 7 DAY) ORDER BY query_time DESC LIMIT 1000;

5.8.关注 top 30 执行全表扫描的SQL

严重程度：★★★★★
问题描述：因为有些 SQL 的执行计划本身其实就有问题的，这些 SQL可能当前跑得很快，但没有评估过数据量增长，当表变得越来越大时，达到一个阀值时，线上可能就会爆发 CPU 100% 的性能问题，成为爆发性杀手级慢查询。全表扫描不仅导致sql执行速度变慢，而且占用系统io资源。如果执行频率较高，会影响整库性能，需重点关注。

5.9.关注 top 30 冗余索引最多的表

严重程度：★★★★
问题描述：查看冗余索引最多的30张表（超过4个以上冗余字段）

select distinct table_schema,table_name,redundant_index_name,redundant_index_columns,sql_drop_index 
from sys.schema_redundant_indexes 
where length(redundant_index_columns)-length(replace(redundant_index_columns,',',''))+1 >= 4 limit 30;

5.10.关注 top 30 无效索引

严重程度：★★★★
问题描述：查看索引使用次数最少的30张表（排除主键），请开发评估是否可以删除

select object_schema,object_name,index_name,count_read,count_write,count_fetch
from performance_schema.table_io_waits_summary_by_index_usage
where index_name <> 'PRIMARY' and index_name is not null 
order by count_read + count_write + count_fetch asc limit 30;

5.11.关注 top 30 索引最多的表

严重程度：★★★
问题描述：索引会加快查询速度，但是单表索引过多除了会占用更多的存储空间之外，还会降低数据写入性能。若超过1000w行，则索引不建议超过5个
检查方法：查看索引最多的30张表（超过6个以上索引）

select database_name,table_name,count(*) as index_count 
from mysql.innodb_index_stats 
where stat_name='size' 
group by database_name,table_name 
having count(*) > 6 
order by index_count desc limit 30;

5.12.关注 top 30 字段最多的索引

严重程度：★★★
问题描述：查看占用字段最多的30个索引（超过6个以上字段）

select database_name,table_name,index_name,count(*)-1 as column_count 
from mysql.innodb_index_stats 
where stat_value=0 
group by database_name,table_name,index_name 
having count(*) > 6
order by column_count desc limit 30;

5.13.是否存在没有主键的表

严重程度：★★★★★
问题描述：MySQL 的玩法就是需要有主键，最好是业务无关的 int signed 自增主键
推荐建议：每张表必须要有主键，强制自增id为bigint(20)，且为主键，业务不要使用

SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_name NOT IN (SELECT DISTINCT table_name FROM information_schema.columns WHERE column_key = "PRI")
AND table_schema NOT IN ('mysql', 'information_schema', 'sys', 'performance_schema') limit 100;

5.14.是否存在 MyISAM 存储引擎表

严重程度：★★★
问题描述：MyISAM 基本没有好处，MySQL 8.0 已将所有系统表更换为InnoDB引擎，默认的MySQL实例将不包含任何MyISAM表，而 MySQL 5.7 可以配置 disabled_storage_engines=MyISAM 来禁用MyISAM引擎（注：MySQL 5.7 仍然有10张元数据表使用 MyISAM 存储引擎，可能会影响数据库的升级）
检查方法：执行下面语句，可以查看哪些表使用的是 MyISAM 存储引擎

select TABLE_SCHEMA,TABLE_NAME,TABLE_TYPE,ENGINE from information_schema.tables where ENGINE='MyISAM' limit 100;

5.15.关注 mysql 连接数

严重程度：★★★★★
问题描述：若mysql实例的最大连接数设置过低，会导致应用程序异常，而过高则会造成服务器资源不足
推荐建议：根据服务器的配置来设置，比如 4C16G 可配置 max_connections=3000，max_user_connections=2500。通常，连接数使用率高于 80% 则需要开始关注，若高于 90% 则需要立即优化

#.连接数使用率 
SELECT 
  max_conn.VARIABLE_VALUE AS max_connections,
  max_user_conn.VARIABLE_VALUE AS max_user_connections,
  conn.VARIABLE_VALUE AS current_connections,
  ROUND(conn.VARIABLE_VALUE / max_conn.VARIABLE_VALUE * 100, 2) AS connection_usage_percent
FROM 
  (SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'max_connections') AS max_conn,
  (SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'max_user_connections') AS max_user_conn,
  (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Threads_connected') AS conn;

5.16.关注 7 天以上僵尸链接

严重程度：★★★★
问题描述：关注7天以上的僵尸链接，僵尸连接过多会导致内存紧张

select id,user,host,db,command,time from information_schema.processlist where command='sleep' and time>3600*24*7;

5.17.关注 30 天以内错误日志

严重程度：★★★★
问题描述：关注最近 30 天的错误日志

#.找出错误日志文件的位置
show variables like 'log_error';

#.查找最近1个月的错误日志, 比如今天是 2026-01-24
grep -E "^(2025-12|2026-01)" error.log | egrep "(ERR|Err|err)"

6.总结和建议

暂时想到这么多，也就是抛砖引玉，性能巡检的目的是出具尽量多的数据给租户自行做性能分析

以上就是个人对 MySQL 数据库巡检需要做什么的总结，欢迎指正。

mysql巡检做些什么

1.系统层面

1.1.CPU

1.2.内存

1.3.磁盘

1.4.网络带宽

2.可用性巡检

2.1.检查实例状态

2.2.检查高可用架构有效性

2.3.检查复制状态

2.4.检查VIP状态

2.5.检查自增id上限

2.6.检查连接失败率

3.可靠性巡检

3.1.检查实例资源配置是否合理

3.2.检查核心参数配置是否合理

3.3.检查主备参数是否一致

3.4.检查运行参数与持久化配置是否一致

4.安全性巡检

4.1.检查是否启用密码复杂度策略

4.2.检查具有super权限的账号

4.3.检查账号的授权范围

4.4.检查防火墙是否开启

4.5.检查空口令或弱口令的账号

4.6.检查备份策略的有效性

4.7.备份文件的恢复测试

4.8.检查SSL传输加密是否开启

4.9.检查加密存储是否开启

4.10.检查审计日志是否开启

5.性能巡检

5.1.关注 InnoDB 缓冲池命中率

5.2关注临时表的使用情况

5.3关注表锁的使用情况

5.4关注Open table的使用情况

5.5.关注 top 20 大库

5.6.关注 top 20 大表

5.7.关注 top 20 慢查询

5.8.关注 top 30 执行全表扫描的SQL

5.9.关注 top 30 冗余索引最多的表

5.10.关注 top 30 无效索引

5.11.关注 top 30 索引最多的表

5.12.关注 top 30 字段最多的索引

5.13.是否存在没有主键的表

5.14.是否存在 MyISAM 存储引擎表

5.15.关注 mysql 连接数

5.16.关注 7 天以上 僵尸链接

5.17.关注 30 天以内 错误日志

6.总结和建议

results matching ""

No results matching ""

5.16.关注 7 天以上僵尸链接

5.17.关注 30 天以内错误日志