目录
一.前置知识点
1. 案例需求
（1）mysql 常见故障解决
（2）mysql 性能优化
2.案例实施思路
（1）单库常见故障分析
（2）主从常见故障分析
（3）从几个不同方面优化mysql
二 案例实施
1.mysql 单实例故障排查
（1）故障现象1
（2）故障现象 2
(3)故障现象 3
（4）故障现象 4
（5）故障现象 5
（6） 故障现象 6
（7）故障现象 7
（8）故障现象 8
2.MYSQL 主从故障排查
（1）故障现象 1
（2）故障现象 2
（3）故障现象 3
3.mysql 优化
（1）硬件方面
1.关于cpu
CPU 对于 MySQL 应用,推荐使用 S.M.P.架构的多路对称 CPU。例如:可以使用两颗 Intel Xeon 3.6GHz 的 CPU。现在比较推荐用 4U的服务器来专门做数据库服务器,不仅仅是针对于MySQL。
2.关于内存
3.关于磁盘
（2）mysql 配置文件
1.核心性能优化项
2.查询优化项
3.日志与监控
4.innodb高级优化
5.示例配置片段 （my.cnf）
（3）sql 方面
1.创建测试表并插入数据
2.使用EXPLAIN 进行 sql 优化的步骤及实验验证
3.优化步骤：添加索引
4.优化后查询及 explain 分析
一前置知识
要学习如何优化,首先要对 MySQL的逻辑架构深入的了解。图8.1是MySQL 逻辑架构图,可以让我们更清晰了解 MySQL 的运行原理
图8.1 中,最上层是一些客户端和连接服务,包含本地 sock 通信和大多数基于客户端/服务器端工具实现的 TCP/IP 通信。主要完成一些连接处理、授权认证、及相关的安全方案等。在该层上引入线程池的概念,为通过安全认证接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
第二层架构主要完成大多数的核心服务功能,如SQL接口、缓存的查询、SQL 的分析和优化以及部分内置函数的执行。所有跨存储引擎的功能也在这一层实现,如过程、函数等。在该层上服务器会解析查询并创建相应的内部解析树,并对其完成相应的优化,如确定查询表的顺序,是否利用索引等,最后生成相应的执行操作。如果是select 语句,服务器还会查询内部的缓存。如果缓存空间足够大,这样在解决大量读操作的环境中能够很好的提升系统的性能。
存储引擎层,存储引擎真正的负责了MySQL 中数据的存储和提取,服务器通过 API与存储引擎进行通信。不同的存储引擎具有的功能不同,可以根据自己的实际需要进行选取。数据存储层,主要是将数据存储在运行于裸设备的文件系统之上,并完成与存储引擎的交互。
1. 案例需求
（1）mysql 常见故障解决
（2）mysql 性能优化
2.案例实施思路
（1）单库常见故障分析
（2）主从常见故障分析
（3）从几个不同方面优化mysql
二 案例实施
1.mysql 单实例故障排查
（1）故障现象1
ERROR 2002 (HY000): Can't connect to local MySQL server through socket
'/data/mysql/mysql. sock' (2)问题分析:以上这种情况一般都是数据库未启动、mysql配置文件未指定socket文件或者数据库端口被防火墙拦截导致。
解决方法:启动数据库或者防火墙开放数据库监听端口。
（2）故障现象 2
ERROR 1045 (28000): Access denied for user 'root' @'localhost' (using
password: NO)问题分析:密码不正确或者没有权限访问。
解决方法:
> 修改 my.cnf 主配置文件,在[mysqld]下添加 skip-grant-tables=on,重启数据库。最后修改密码命令如下。
mysql15.7版本
mysql> update mysql. user set authentication_string=password('123456')
where user=' root'
and Host = 'localhost' ;
mysql> flush privileges;mysql 18.0 版本
mysql> UPDATE mysql. user SET authentication_string='' WHERE user=' root'
AND Host=' localhost' ;
mysql> FLUSH PRIVILEGES;
mysql> ALTER USER 'root' @'localhost' IDENTIFIED BY '123456' ;> 再删除刚刚添加的skip-grant-tables 参数,重启数据库,使用新密码即可登录。重新授权,命令如下。
mysql15.7
mysql>grant all on *. * to 'root'@'mysql-server' identified by'123456' ;mysql18.0
mysql> CREATE USER 'root' @'mysql-server' IDENTIFIED BY'123456' ;
mysql> GRANT all ON *.* TO 'root'@'mysql-server' ;(3)故障现象 3
在使用远程连接数据库时偶尔会发生远程连接数据库很慢的问题。
问题分析:如果 MySQL 主机查询 DNS 很慢或是有很多客户端主机时会导致连接很慢. 由于开发机器是不能够连接外网的,在进行MySQL 连接时,DNS 解析是不可能完成的,从而也就明白了为什么连接那么慢了。
解决方法:修改 my.cnf 主配置文件,在[mysqld]下添加 skip-name-resolve,重启数据库可以解决。注意在以后授权里面不能再使用主机名授权。
（4）故障现象 4
Can't open file: 'xxx_forums. MYI'. (errno: 145)问题分析:
服务器非正常关机,数据库所在空间已满,或一些其它未知的原因,对数据库表造成了损坏。
> 可能是操作系统下直接将数据库文件拷贝移动,会因为文件的属组问题而产生这个错误.
解决方法:
可以使用下面的两种方式修复数据表(第一种方法仅适合独立主机用户):
。。。》使用 MySQL 自带的专门用户数据表检查和修复工具 myisamchk。一般情况下只有在命令行下面才能运行 myisamchk 命令。常用的修复命令为:
myisamchk -r 数据文件目录/数据表名.MYI;
。。。》■ 通过 phpMyAdmin 修复,phpMyAdmin 带有修复数据表的功能,进入到某一个表中后,点击“操作”,在下方的“表维护”中点击“修复表”即可。
注意:以上两种修复方式在执行前一定要备份数据库。
> 修改文件的属组(仅适合独立主机用户):
。。。》复制数据库文件的过程中没有将数据库文件设置为MySQL 运行的帐号可读写(一般适用于Linux 和 FreeBSD 用户)。
（5）故障现象 5
ERROR 1129 (HY000): Hostxxx. xxx. xxx. xxx' is blocked because of manyconnection errors;unblock with 'mysqladmin flush-hosts'问题分析:由于 mysql 数据库的参数:max_connect_errors,其默认值是10。当大量(max_connect_errors)的主机去连接MySQL,总连接请求超过了10次,新的连接就再也无法连接上 MySQL 服务。同一个ip在短时间内产生太多中断的数据库连接而导致的阻塞(超过mysql数据库max_connection_errors的最大值)。
解决方法:
> 使用 mysqladmin flush-hosts 命令清除缓存,命令执行方法如下:
mysqladmin -uroot -p -h 192.168.241.48 flush-hostsEnter password:
>修改 mysql 配置文件,在[mysqld]下面添加 max_connect_errors=1000,然后重启MySQL。
（6） 故障现象 6
客户端报 Too many connections。
问题分析:连接数超出 Mysql 的最大连接数限制。
解决方法:
在my.cnf 配置文件里面增大连接数,然后重启 MySQL 服务
max_connections = 10000
> 临时修改最大连接数,重启后不生效。需要在 my.cnf 里面修改配置文件,下次重启生效。
set GLOBAL max_connections=10000;
（7）故障现象 7
Warning: World-writable config file '/etc/my.cnf' is ignored
ERROR! MySQL is running but PID file could not be found问题分析:MySQL的配置文件/etc/my.cnf 权限不对。
解决方法:
chmod 644 /et/my. cnf（8）故障现象 8
InnoDB: Error: page 14178 log sequence number 29455369832
InnoDB: is in the future! Current system log sequence number 29455369832问题分析:innodb 数据文件损坏。
解决方法:修my.cnf 配置文件,在[mysqld]下添加innodb_force_recovery=4,启动数据库后备份数据文件,然后去掉该参数,利用备份文件恢复数据。
2.MYSQL 主从故障排查
（1）故障现象 1
从库的 Slave_I0_Running 为 NO
The slave I/0 thread stops because master and slave have equal MySQL server
ids; these ids must be different for replication to work (or the
-- replicate-same-server-id option must be used on slave but this does not
always make sense; please check the manual before using it).问题分析:主库和从库的 server-id 值一样。
解决方法:修改从库的server-id 的值,修改为和主库不一样。修改完后重启,再同步即可。
（2）故障现象 2
从库的 Slave_IO_Running 为 NO问题分析:造成从库线程为 NO的原因会有很多,主要原因是主键冲突或者主库删除或更新数据,从库找不到记录,数据被修改导致。通常状态码报错有 1007、1032、1062、1452等。
解决方法一:
mysql> stop slave;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> start slave;解决方法二:
设置用户权限,设置从库只读权限
set global read_only=true;（3）故障现象 3
Error initializing relay log position: I/0 error reading the header from
the binary log分析问题:从库的中继日志 relay-bin 损坏。
解决方法:手工修复,重新找到同步的binlog和pos点,然后重新同步即可。
mysql>CHAN GEMASTER TO MASTER_LOG_FILE=' mysq1-bin. xxx', MASTER_LOG_POS=xxx;3.mysql 优化
（1）硬件方面
说到服务器硬件,最主要的无非CPU、内存、磁盘三大关键因素。
1.关于cpu
CPU 对于 MySQL 应用,推荐使用 S.M.P.架构的多路对称 CPU。例如:可以使用两颗 Intel Xeon 3.6GHz 的 CPU。现在比较推荐用 4U的服务器来专门做数据库服务器,不仅仅是针对于MySQL。
2.关于内存
物理内存对于一台使用 MySQL的 Database Server 来说,服务器内存建议不要小于2GB,推荐使用 4GB 以上的物理内存。不过内存对于现在的服务器而言可以说是一个可以忽略的问题,工作中遇到了高端服务器基本上内存都超过了32G.
3.关于磁盘
磁盘寻道能力(磁盘 I/0)。以目前市场上普遍高转速 SAS硬盘(15000转/秒)为例,这种硬盘理论上每秒寻道 15000次,这是物理特性决定的,没有办法改变。MySQL 每秒钟都在进行大量、复杂的查询操作,对磁盘的读写量可想而知。所以通常认为磁盘 I/0是制约MySQL 性能的最大因素之一,通常是使用RAID-0+1 磁盘阵列,注意不要尝试使用RAID-5,MySQL在 RAID-5 磁盘阵列上的效率并不高。如果不考虑硬件的投入成本,也可以考虑固态(SSD)硬盘专门作为数据库服务器使用。数据库的读写性能肯定会提高很多。
（2）mysql 配置文件
1.核心性能优化项
参数 作用 建议配置 注意事项 innodb_buffer_pool_size InnoDB缓冲池大小,和索引,直接影响读性能。 设置为物理内存的
50%~70%(如 64GB
内存配40G)。避免超过物理内存,防止系统交
换(Swap)。
innodb_log_fi le_size单个InnoDB
做日志文件志
大小,影响建议1G 4GInnoDB重(如2G),做日志文件志
大小,影响
注意事项
个建
重(如(innodb_log_fil
总日修改需停止 MySQL,删除旧日志大小文件后重启。
参数 作用 建议配置 注意事项 事务提交速es_in_group
度和崩溃恢size)。
复时间。
控制事务日1(默认,完全持久
innodb_flush_ 志刷新策化)
log_at_trx_commit 略,平衡性2(折中,每秒刷盘)
能与数据安0(高性能,风 险高）险高并发写入场景可设为 2,但需
容忍最多 1秒数据丢失。max_connectionsnsns 根据业务需求设
最大客户端置,建议500~2000连接数,避免配连接耗合尽_size(如 100)缓
存线程。监控
thread_cache
Threads_connected和thread_cache
hreads_running 调整。内存临时表 建议 64M~256M,
tmp_table_size大小上限, 两者值需一 致两者值需一致 128M)。如
。
影响复杂查询(如GROUP BY,
JOIN)max_heap_table_size
过小会导致磁盘临时表,降低性
能;过大可能耗尽内存。
2.查询优化项
参数 作用 建议配置 query_cache_type 查询缓存类型(MySQL 8.00FF(默认,高并发下建议关已移除,旧版本慎用)。闭)。 sort_buffer_size 排序操作缓冲区大小。 2M~8M,过大浪费内 存
(如 4M)。join_buffer_size
read_rnd_buffer_siz
read_buffer_size
JOIN 操作缓冲区大小。
4M~16M,仅对 无索引 JOIN
有效(8M)。
2M~8M(如 4M)。
4M~16M(如 8M)。顺序读缓冲区大小。
随机读缓冲区大小。
3.日志与监控
参数
slow_query_log
作用
启用慢查询日志,ON
建议配置
参数 作用 建议配置 记录执行时间长的
SQL.
定义慢查询阈值1~2(根据业务容忍度调整)。(秒)。错误日志路径,用于故障排查。指定路径(如 /var/log/mysql/error.log)
二进制日志格式
ROW(推荐,数据一致性高)。
(主从复制依赖)自动清理旧的二进
制日志天数。7~14(根据备份策略调整)。
long_query_time log_error binlog_format expire_logs_days
4.innodb高级优化
参数 作用 建议配置 innodb_io_capacity InnoDB 后台任务的
I/0 能力(如刷新脏 SSD 建议 2000~4000,HDD 建议200400。
页)。控制数据文件与日
志文件的刷新方式。 0_DIRECT(默认,避免双缓冲)。InnoDB 并发线程数限制。
0_DIRECT(默认,避免双缓冲)。
景可设为 CPU 核数 *2。
自增锁模式,影响插入性能。2(连续模式,高并发插入推荐)。
innodb_flush_method innodb_thread_concurrency innodb_autoinc_lock_mode
5.示例配置片段 （my.cnf）
物理资源 32核CPU、64G内存、500G SSD
[mysqld]
#核心配置
innodb_buffer_pool_size = 40G
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2
max_connections = 1000
thread_cache_size = 100
# 查询优化
tmp_table_size = 128M
max_heap_table_size = 128M
sort_buffer_size = 4M
join_buffer_size = 8M
# 日志与监控
slow_query_log = ON
long_query_time = 1
log_error =/var/log/mysql/error. log
binlog_format = ROW
expire_logs_days = 7
# InnoDB 高级
innodb_io_capacity = 2000
innodb_flush_method = O_DIRECT
innodb_thread_concurrency = 0
innodb_autoinc_lock_mode = 2（3）sql 方面
SQL优化是确保数据库高效运行的关键,其核心在于通过减少资源消耗(如CPU、内存、磁盘I/0)来提升查询响应速度,避免慢查询导致用户体验下降或系统崩溃。未优化的SQL可能引发全表扫描、冗余计算或锁竞争,尤其在数据量大或高并发场景下,会导致服务器负载飙升、响应延迟,甚至影响业务连续性(如交易超时)。通过索引调优、查询改写、执行计划分析等手段,可显著降低数据库压力,支撑业务规模扩展,同时控制硬件成本与运维复杂度。
1.创建测试表并插入数据
--
创建测试库
Create database test;
创建用户表
Use test;
CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR (50) NOT NULL,
email VARCHAR(100) NOT NULL,
age INT NOT NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- 插入 10 万条测试数据(使用存储过程生成)
DELIMITER $$
CREATE PROCEDURE insert_users ()
BEGIN
DECLARE i INT DEFAULT 0;
WHILE i < 100000 DO
INSERT INTO users (name, email, age)
VALUES (CONCAT('user', i), CONCAT('user', i, '@example.com'),
FLOOR(RAND()*100));
SET i=i+1;
END WHILE;
END$$
DELIMITER
CALL insert_users () ;2.使用EXPLAIN 进行 sql 优化的步骤及实验验证
EXPLAIN 是 MySQL 中用于分析 SQL 执行计划的工具,通过模拟查询执行过程输出关键信息(如访问类型 type、使用索引 key、预估扫描行数额外操作rows,等),帮助开发者识别全表扫描、索引失效等性能瓶颈,从而指导优化方向(如添加引、改写查询或调整表结构),是提升数据库效率不可或缺的诊断手段。
例如:
mysq1>EXPLAIN SELECT * FROM users WHERE name ='user123' ;mysql> EXPLAIN SELECT * FROM users WHERE name = 'user123';
id
1 | SIMPLE
row in set, 1 warning (0.00 sec)
select_type
table
users
partitions
NULL
type
ALL
possible_keys
NULL
key
NULL
key_len
NULL
+
ref
NULL
rows
99870
filtered
10.00
Extra
Using whereEXPLAIN 用于显示 MySQL 如何执行一条 SQL 语句,关键字段如下:
字段 说明 优化关注点
id 查询序列号,相同id 为同一执行
层,不同id 按序执行(如子查复杂查询的嵌套层级。
询)。
查询类型(SIMPLE、PRIMARY、
select_type SUBQUERY、DERIVED 等)。
访问的表名或别名。
table 识别子查询或临时作。
确认查询涉及的表
字段 说明 优化关注点、
type 访问类型,性能从优到劣: 避免 ALL(全表扫描优先
system > const > eq_ref > ref> 优化为 ref或range .
range>index > ALL. 检查是否有合适索引未被用。
possible_keys 可能使用的索引。
key 实际使用的索引。 确认是否命中最佳引。行数越少,查询效率越高。
rows 预估扫描的行数。附加信息(如Using where .Using
Extra Using indextemporar 等) 发现潜在性能问题(如临时表、
文件排序)。根据关键字说明,对explain SELECT * FROM users WHERE name ='user123';的结果分析如下
type=ALL:全表扫描,效率极低。
possible_keys=NULL:未命中索引。
rows=100000:扫描全部数据。
3.优化步骤：添加索引
mysql>ALTER TABLE users ADD INDEX idx_name (name);4.优化后查询及 explain 分析
users | NULL
mysql> ALTER TABLE users ADD INDEX idx_name (name);
Query OK, 0 rows affected (0.23 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> EXPLAIN SELECT * FROM users WHERE name = 'user123';
id | select_type | table | partitions | type | possible_keys | key
1 | SIMPLE
1 row in set, 1 warning (0.00 sec)
ref
idx_name
idx_name
| key_len | ref
152
const
1 |
| rows | filtered | Extra |
| NULL
100.00优化后结果分析如下:
type=ref:索引查找,效率高。
key=idx_name:命中新创建的索引。
rows=1:仅扫描一行数据。
