先讲个我见过太多次的场景：新人装MySQL，敲完apt install mysql-server或者yum install mysql-server，看到提示成功了，心里觉得“完事”，结果第二天项目一跑，要么连接数被打满，要么中文乱码，要么慢查询堆成山，只能干瞪眼。问题出在哪？出在“装上了”和“能用好”是两码事。数据库这东西，安装只是入场券，配置才是你真正干活的部分。
这篇就来聊聊MySQL从安装到配置的完整落地过程，覆盖版本选择、安装方式选型、核心配置文件拆解、权限和安全初始化，以及我这些年踩过的坑和处理套路。适合刚入行的后端开发、运维新手，以及那些“用了好几年MySQL但没认真看过配置”的同学。我会把每个关键步骤背后的原因讲清楚，不搞云里雾里的官话，你照着做就能在自己机器上跑出一套健壮的实例。
1. 动手之前：版本、安装方式和目录规划
1.1 版本怎么选：别迷信“最新”
很多人上来就问“我装8.0还是装最新的8.4？”，其实这个问题得反过来想：你的业务和周边生态支持什么版本。
MySQL的版本演进里，5.7是上一代的经典稳定版，8.0是当前绝对的主流。8.0带了一堆实质性改进：默认字符集变成了utf8mb4、查询缓存被彻底移除、引入了窗口函数和CTE、底层数据字典重构、性能大版本提升了不止一个档次。如果你是全新的项目，没有历史包袱，直接上8.0，别犹豫。但如果你是接手老项目，代码里还跑着“很久以前的SQL写法”，那就要先确认应用兼容性，有些老驱动连8.0的默认认证插件都过不去。
我的建议很简单：新项目优先8.0系列，版本号选最新小版本（比如8.0.3x+），因为修复了不少已知bug。至于5.7，除非你的老系统有强约束，否则没必要在新环境里再开历史倒车。另外记住一条铁律：
提示：不要在生产环境用“最新大版本”尝鲜。比如大版本刚发布的初期小版本，往往是踩坑高发期。选一个发布了半年以上的稳定小版本，社区和文档都跟得上，出了问题也好查。
1.2 三种安装方式，各自什么时候用
MySQL的安装方式，实践中就三类：包管理器安装、二进制包解压安装、源码编译安装。我一个个说清楚各自的适用场景。
包管理器（apt/yum/dnf）安装是绝大多数场景的首选。好处是依赖自动解决、自带systemd服务单元、升级卸载都方便。缺点是版本受发行版仓库控制，可能不是你想要的最新版本。比如某些稳定版发行版的默认仓库里，MySQL版本还停留在较老的版本。解决办法是使用MySQL官方提供的APT/Yum仓库，把官方源加进来就能装到较新版本，这个下面实操部分会写。
二进制包安装（也就是tar.gz那种）适合离线环境、批量交付、或者你不想污染系统包管理的场景。解压之后做几个软链或配置环境变量就能用，逻辑清晰。缺点是依赖得自己检查，服务脚本得自己写，数据目录得自己初始化。数据库软件本身是“绿色版”，但你需要把它“种”进系统里。
源码编译安装适合有特殊编译需求或做二次开发的人。普通业务环境基本用不到，而且编译耗时长、依赖多，我不建议为了“显得专业”而去编译安装。生产环境里，时间和可维护性都比“成就感”重要。
1.3 安装前的环境检查清单
不管哪种方式，动手前花十分钟做三件事，能省后面十个小时。第一，确认操作系统版本和架构，命令大概是cat /etc/os-release和uname -m。x86_64是主流，如果你用的是ARM架构的机器，注意对应下载ARM版本的包。第二，检查依赖库，Linux下最常见的是libaio，MySQL运行时刻依赖它，提前装上省得到时候报错一头雾水。第三，规划数据目录。
数据目录规划这个事，很多人忽略。默认情况下数据目录跟着安装包走，比如/var/lib/mysql。如果你只是本地开发或测试，那无所谓。但生产环境，我强烈建议把数据盘单独挂载，比如/data/mysql，并把数据目录指向那里。原因很简单：系统盘一般空间有限，日志和binlog会把磁盘吃光；而且数据盘独立之后，做快照、扩容、迁移都方便得多。这个决策在安装时定下来，比装完再迁要省事太多。
注意：数据目录在初始化之后就不要随意改动位置了。如果必须迁移，请先停库，再用
--datadir参数重新指定并做完整数据校验，不要直接mv目录了事。直接移动目录而不改配置，极大概率导致启动失败或数据不可用。
2. 实操：从安装到数据库能连上
2.1 用官方仓库安装（最推荐的路径）
以Debian/Ubuntu系的系统为例，先装基础组件，再导入官方仓库的GPG密钥，然后把仓库地址写进源列表。顺序大概是：
sudo apt update sudo apt install -y gnupg lsb-release wget -c 官方仓库的deb包地址 sudo dpkg -i 下载的deb包 sudo apt update sudo apt install -y mysql-server这里有几个细节要说。第一，官方仓库的deb包地址不要凭记忆写，去MySQL官方文档页找当前版本的下载链接，用wget之前先确认URL没写错，404是新手最常见的坑。第二，仓库导入之后，apt update的输出里应该能看到MySQL仓库的源，确认它出现了再进行安装。第三，apt安装mysql-server时会自动拉起服务并生成root的auth_socket认证配置，这个后面安全初始化时再处理。
Red Hat/CentOS系则用yum仓库，步骤异曲同工：下载对应的rpm包（mysql80-community-release）安装，它会把仓库配置写到/etc/yum.repos.d/下，然后yum install mysql-community-server就完事。安装完成后，CentOS系默认还会自动做一次初始化并生成临时root密码，注意查看日志文件里的记录。
安装完之后，启动服务并设置开机自启：
sudo systemctl enable --now mysqld sudo systemctl status mysqld看到active (running)就说明服务起来了。如果你发现状态是failed，别慌，先去查错误日志，后面专门的排查章节会讲。
2.2 二进制包安装（离线环境适用）
如果你面对一台完全离线的机器，包里管理器这条路就走不通了，这时候二进制包是救命的那条。操作流程我说的细一点，每一步都有它的道理。
先下载对应版本的tar.gz包（比如mysql-8.0.x-linux-glibc2.17-x86_64-minimal.tar.xz这种），解压到指定目录。我习惯放在/usr/local/，然后做个软链：
sudo tar -xJf mysql-8.0.x-linux-x86_64.tar.xz -C /usr/local/ sudo ln -s /usr/local/mysql-8.0.x /usr/local/mysql接着创建专用的系统用户。MySQL强烈建议不要用root跑服务，安全原因很明显：数据库进程一旦被打穿，攻击者拿到的直接就是root权限。创建用户和目录归属：
sudo groupadd mysql sudo useradd -r -g mysql -s /bin/false mysql sudo mkdir -p /data/mysql sudo chown -R mysql:mysql /data/mysql sudo chown -R mysql:mysql /usr/local/mysql然后初始化数据目录。8.0之后用的是--initialize模式，它会生成一个临时root密码：
sudo /usr/local/mysql/bin/mysqld --initialize --user=mysql --datadir=/data/mysql执行完，记下日志里输出的临时密码，通常是[Note] A temporary password is generated for root@localhost: xxxxxxxx。如果你自己写配置文件，里面指定了默认的error-log路径，那就去那个日志文件里找。这个密码是一次性的，首次登录后必须改掉。
最后做systemd服务单元。虽然官方包不带，手写一个也就几行，瞅一眼配置：
[Unit] Description=MySQL Server After=network.target [Service] User=mysql Group=mysql ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf LimitNOFILE=65535 Restart=on-failure [Install] WantedBy=multi-user.target写到/etc/systemd/system/mysqld.service，然后systemctl daemon-reload、systemctl start mysqld。二进制包安装的流程到此就通了。
2.3 首次登录和基本验证
服务起来之后，用临时密码登录：
mysql -uroot -p ALTER USER 'root'@'localhost' IDENTIFIED BY '你的新密码';8.0默认密码插件是caching_sha2_password，大多数新驱动都支持，但如果你的老应用报认证插件不支持的错，可以单独给应用账号改成mysql_native_password。这个我们权限那节再讲。
登录后跑几个SQL，确认基本盘是正常的：
SELECT VERSION(); SHOW VARIABLES LIKE 'datadir'; SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'port';到这里，一个能连的MySQL就算立住了。但注意：这还只是“能跑”，离“能扛事”差得远，配置优化才是重头戏。
3. 配置文件深度拆解：别再做“默认参数侠”
3.1 配置文件在哪，优先级是什么
MySQL配置文件的加载顺序是个老生常谈的问题，但每次都有朋友搞错。Linux下，mysqld启动时按顺序读取以下位置的文件，先读到的先生效：
/etc/my.cnf/etc/mysql/my.cnf/usr/local/mysql/etc/my.cnf~/.my.cnf
实际情况里，/etc/my.cnf基本是事实标准。官方仓库安装的版本，你会在/etc/mysql/my.cnf里看到一串!includedir引用/etc/mysql/conf.d/和/etc/mysql/mysql.conf.d/，两层目录结构，初始配置都散在那些子文件里。我个人的习惯是：写一个主配置文件/etc/my.cnf，把核心参数集中在里面，不用分散include的玩法，排查问题时候一眼能看完所有关键配置。
注意：配置文件修改之后需要重启MySQL才生效，这一点和某些参数可以用SET GLOBAL动态修改不同。判断一个参数能否动态生效，看官方文档里对应变量的
Dynamic字段。我建议，修改配置文件后再重启服务作为最终动作，动态修改只用来应急。
3.2 [mysqld] 基础段：数据目录、字符集、连接
配置文件有分区，常见的是[mysqld]、[mysql]、[client]这些标签段。最重要的就是[mysqld]，它管的是服务端的核心行为。以下是我每台新机器上都会落的参数：
[mysqld] user = mysql port = 3306 bind-address = 0.0.0.0 socket = /tmp/mysql.sock datadir = /data/mysql character-set-server = utf8mb4 collation-server = utf8mb4_0900_ai_ci default-storage-engine = InnoDB每一条拆开讲。
port默认3306，没特别理由不要改。改了端口看似“安全”，其实纯属给自己找麻烦，应用侧、防火墙、监控工具全要跟着改，而安全性基本没有提升，真正的安全要靠账号权限和防火墙规则去保证。
bind-address这个参数要分场景。默认通常是127.0.0.1，意思只允许本机连接，这样最安全。但如果你是应用服务器和数据库服务器分离部署，那就要改成0.0.0.0监听所有网卡。这里有个平衡点：如果真的只需要本机连，就别图省事改成0.0.0.0，少暴露一个端口，少一份被扫描的风险。
character-set-server和collation-server我固定写utf8mb4。utf8mb4才是真正的“全量Unicode”，能存emoji和大部分生僻字，而老式的utf8（utf8mb3）在8.0里已经属于废弃状态，不要往上面放新业务。默认排序规则选utf8mb4_0900_ai_ci，这是8.0默认，大小写不敏感、重音不敏感，绝大多数业务都要这种表现。
default-storage-engine = InnoDB这行在8.0里其实可以不用写，InnoDB已经是默认引擎了。但我还是写上，算是显式声明。InnoDB支持事务、行级锁、崩溃恢复，目前所有正经业务都应该用它。MyISAM这种老古董，除非你遇到极特殊的只读场景，否则别去碰。
3.3 性能参数：缓冲池和内存怎么给
配置里最容易造成困惑的是性能参数，因为它牵扯到“这台机器到底多大内存”。我给你的思路是：先看机器物理内存，再按比例分配，而不是照抄网上的“万能模板”。
最重要的是innodb_buffer_pool_size。这是InnoDB缓存表和索引数据的内存区域，是MySQL性能的定盘星。业界经验值通常是物理内存的50%到70%。比如一台16G内存的专用数据库服务器，buffer pool给10G就是个合理的起点。计算公式比较好记：
# 物理内存 16G，分配约60% innodb_buffer_pool_size = 10G别贪多。机器上还有操作系统页缓存、连接线程栈、sort/join缓冲、临时表空间等等一堆要内存的地方，全塞给buffer pool，一次并发峰值就可能导致内存交换。8.0之后还支持设置多个buffer pool instance，参数是innodb_buffer_pool_instances，默认情况一个buffer pool分8个实例，能减少并发访问的锁竞争，这个保持默认即可，不需要刻意设置。
max_connections这个参数是个双刃剑。默认值151，对小型应用够用，但规模一大就等着报Too many connections。常见做法是调大到500或1000。但你要清楚：连接数不是一个可以无限调大的数字。每个连接都要消耗内存做线程栈，默认情况下一个连接大概几MB的额外占用。所以调大连接数之前，先想清楚应用侧连接池的配置，Spring/Druid这类连接池通常几十个连接就足矣，没必要让数据库抗几千连接。这里有个取舍原则：
提示：连接数的正确姿势是“应用池化 + 数据库合理上限”。数据库侧开2000连接，不如把应用连接池压到100连接以内，数据库压力小一个量级。
其他性能相关参数里，innodb_log_file_size值得单独说。这是redo log的大小，默认值是32M（8.0早期版本甚至更小）。redo log太小会导致日志频繁切换刷盘，影响写入性能，尤其是高并发写场景。通常我建议调到256M到1G之间，和innodb_log_files_in_group配合。不过这组参数改动需要重启，而且Resize的机制在8.0里支持在线调整，但为了保险，还是停机改配置再重启最稳。
table_open_cache控制的是表描述符的缓存数量。默认值4000通常够用，如果你库里的表非常多，或者频繁开关表的连接很多，可以调大，但没必要一开始就动它。还有innodb_flush_log_at_trx_commit，这是事务提交时日志刷盘策略。默认值是1，即每次提交都刷盘，最安全，最多丢失零个事务。性能敏感、对数据一致性要求能妥协一点的场景，可以设为2，但生产环境我不建议改这个，一条数据都是钱。
3.4 日志参数：别等出事了才想起看日志
MySQL的日志体系，新手最容易混为一谈。实际上分三类：错误日志（error log）、慢查询日志（slow query log）、二进制日志（binlog）。我建议装完就都配置好，别等出了问题再临时抱佛脚。
# 错误日志 log_error = /var/log/mysql/error.log # 慢查询日志 slow_query_log = ON slow_query_log_file = /var/log/mysql/slow.log long_query_time = 2 # 二进制日志 server-id = 1 log-bin = /var/log/mysql/binlog binlog_format = ROW错误日志是一切故障排查的起点，启动失败、权限问题、数据库损坏，全部都会记录在这里，不配有错误日志，你就等于蒙着眼睛开车。
慢查询日志定位“SQL为什么慢”，设置long_query_time = 2表示执行超过2秒的SQL会被记录下来。这2秒是个经验值，没有绝对标准，如果业务普遍比较快可以先从1秒开始抓，慢查询日志记录的是执行时间，不包含等待锁的时间，这个要格外注意，分析时别被误导，真的在锁上等的人，要用performance_schema。
二进制日志这个很多人容易忽略。binlog记录的是所有修改数据的操作，配合备份才能做到“恢复到任意时间点”。生产环境无论如何都要开。binlog_format = ROW是8.0默认，也是推荐值，行级日志更安全可靠。开了binlog就要配套设置server-id，否则主从和多实例环境会出错，这是个连环套，少哪个都不行。
4. 安全初始化：root密码、密码策略和最小权限
4.1 第一件事：跑一遍安全初始化脚本
安装MySQL之后，系统里其实存在的是“裸奔”状态的root账号。Debian系默认的root走auth_socket，即只有系统root用户能直接登录MySQL的root；CentOS系会生成一个随机临时密码，但它默认绑定了localhost且没有特殊限制。不论什么情况，都需要明确完成安全初始化。
最省事的方式是MySQL自带的mysql_secure_installation脚本，跟着提示一路下来，它会帮你：设置root密码、移除匿名账号、禁止root远程登录、删除test测试库、重新加载权限表。注意8.0里这个脚本是新版对话框风格，按回车或输Y/N即可，本质上执行的也就是那几条SQL。
不过我的实际建议是：默认的脚本可以跑，但跑完之后你还要手动去理解它到底做了啥，别把它当黑盒用。它做的事情拆开就是：
DELETE FROM mysql.user WHERE User=''; ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY '你的密码'; DROP DATABASE IF EXISTS test; FLUSH PRIVILEGES;懂了这个逻辑，以后哪怕脚本不可用，你也能手动执行。
4.2 密码策略：不调好策略，改密码会被拒
8.0自带validate_password组件。如果你给root改一个简单密码（比如123456），会被直接拒绝，提示不符合密码策略。这里面涉及几个变量：
validate_password.policy：0=LOW（只查长度）、1=MEDIUM（长度+数字+大小写+特殊字符）、2=STRONG（还要查字典文件）validate_password.length：最小长度，默认8
开发环境你可以适当放宽，生产环境放着默认策略就好。改策略的方式：
SET GLOBAL validate_password.policy = LOW; SET GLOBAL validate_password.length = 6;注意改的是运行时的值，如果想永久生效，要把对应项写进配置文件[mysqld]段。另外注意组件和插件在8.0里是两回事，检查它有没有安装，用：
SELECT * FROM performance_schema.global_status WHERE variable_name LIKE 'validate%';4.3 业务账号：最小权限原则是底线
很多事故都是因为“图省事”导致的。某个业务账号直接授了ALL PRIVILEGES ON *.*，或者开发环境用的账号直接能删全库。我的原则是：每个业务单独建账号，权限精确到库表，能不给写就不给写，能不给全局就不给全局。
创建专用账号的标准姿势：
CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY '强密码'; GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'app_user'@'192.168.1.%'; FLUSH PRIVILEGES;几点说明。第一，host部分写'192.168.1.%'是限定来源网段，比写'%'安全得多。如果应用和数据库在同一台机器，就写'localhost'，连网段都不开。第二，mydb.*表示只对mydb库的所有表有权限，没给DDL权限，想改表结构就得走DBA执行，这天然形成一道变更审批的门槛。第三，FLUSH PRIVILEGES只在直接操作user表时才必须执行，用GRANT/CREATE USER的语句会自动生效，但多执行一次也没坏处。
额外说一个坑：8.0默认认证插件是caching_sha2_password，老版本的应用驱动（比如5.x时代的某些语言的mysql驱动）可能不支持，报错形如Authentication plugin 'caching_sha2_password' cannot be loaded。处理方式有两个，一个是升级驱动，这是正路；另一个是为该账号单独指定老插件：
CREATE USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY '强密码';这个算是过渡方案，能不用就不用。
5. 日常运维：日志管理、备份与监控
5.1 备份：mysqldump只适合中小型库
备份这件事，我见过太多惨剧，都是“从来没备份过”，或者“备份了但从没恢复过”。你要记住一句话：没有验证过的备份，等于没有备份。
中小型库（几个G到几十个G）用逻辑备份mysqldump完全够用：
mysqldump -u root -p --single-transaction --routines --triggers --events mydb > mydb_$(date +%F).sql--single-transaction利用InnoDB的一致性快照做非锁备份，线上业务也能跑，不会锁住线上写入，这是必须带上的参数。恢复时用mysql -u root -p mydb < mydb_2025-01-01.sql。注意恢复之前确保目标库已经建好且字符集一致，不然很可能恢复出乱码。
大库（几百G以上）用逻辑备份就不现实了，耗时太长且恢复也慢。这时候要上物理备份工具，最简单的是直接拷贝数据目录（必须一致快照，比如用LVM快照），或者使用专业的物理备份方案，这里不展开细讲，但思路是：全量备份 + binlog增量，实现按时间点恢复。
5.2 定时备份脚本的合理结构
我一般用一个简单的脚本，cron里每天跑，日志单独留档。脚本里值得说的几个点：备份文件名带日期方便回滚；备份前检查磁盘剩余空间；备份后用mysqlcheck或者重新导入一次到临时库校验完整。脚本写完放/usr/local/bin/backup_mysql.sh，crontab里加一行：
0 2 * * * /usr/local/bin/backup_mysql.sh >> /var/log/mysql_backup.log 2>&1凌晨2点是业务低谷，备份对线上影响最小。日志和备份文件分开放，防止磁盘打满之后两边都写不进去。
5.3 看一眼就懂的监控三板斧
监控不是非得搭一套完整系统，日常巡检可以先从几个查询入手。第一板斧是看连接和线程状态：
SHOW GLOBAL STATUS LIKE 'Threads_connected'; SHOW GLOBAL STATUS LIKE 'Threads_running';Threads_running是正在执行的线程数，这个值如果长期超过几十，说明负载很高。第二板斧是看慢查询数量：
SHOW GLOBAL STATUS LIKE 'Slow_queries';和慢查询日志对照，能快速判断“是有偶发慢SQL”还是“系统性变慢”。第三板斧是看InnoDB的读写和缓冲池命中率：
SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests'; SHOW STATUS LIKE 'Innodb_buffer_pool_reads';两个值一除，命中率应该在99%以上才正常，低于95%说明buffer pool给小了或者冷数据太多。
这套“三板斧”不需要额外装任何工具，DBA的本能就是先会用SQL看库，再上监控系统。监控系统是辅助，不是替代。
6. 踩坑记录与快速排查实录
6.1 安装阶段的经典报错
先说最常见的确认坑：官方仓库导入后执行apt update报404或者GPG key错误。GPG key错误一般是没用apt-key adv --keyserver导入新key，老的key过期导致的。处理方式是重新从官方源拉取最新的key文件并导入。404则是仓库地址和你系统版本不匹配，比如你是新版本系统，但仓库源里没有对应的组件，此时需要检查/etc/apt/sources.list.d/mysql.list里面的发行版代号字段对不对。
依赖缺失的经典报错是libaio.so.1: cannot open shared object file。这是二进制包安装时最常见的，因为从源码构建的最小包不会带上系统依赖的自动解析。解决方式：
sudo apt install -y libaio1 # Debian/Ubuntu sudo yum install -y libaio # CentOS/RHEL还有一个包管理器安装时的隐藏坑：如果系统里之前装了系统自带的mariadb，再装MySQL会撞端口或者文件冲突。建议先彻底移除mariadb及相关包，清理干净/var/lib/mysql，再开始装MySQL。
6.2 服务启动失败的排查流程
服务起不来，第一件事永远是看错误日志，不是看systemctl的输出。启动失败的典型原因有三个。第一个是数据目录权限不对，表现为日志里Permission denied，处理方式就是确保mysql用户对datadir有读写权限。第二个是配置文件里的datadir和实际目录不一致，启动时mysqld找不到数据文件，日志里会报路径不存在的错误。第三个是端口被占用，用ss -lntp | grep 3306排查，可能是之前残留的实例还在跑。
还有个8.0特有但很少人提的坑：数据目录里之前已经初始化过，再次--initialize会报错说目录非空。处理方式是清空或者换一个新目录。但要非常小心，清空目录之前先确认这个目录里没有你需要的业务数据，这是不可逆操作。
6.3 连接不上的几种可能
“我能连上SSH但连不上MySQL”是求助高频问题。排查思路按顺序来：先看MySQL进程在不在，再看端口在不在听，再看防火墙有没有放行，最后看账号的host权限。
一条命令查端口：
ss -lntp | grep 3306如果只听到了127.0.0.1:3306，说明bind-address配置限制在本机，外部连接自然失败，去改配置。确认端口没问题后，看防火墙规则，云服务器尤其要检查安全组规则，这是被忽略最多的地方。最后用SELECT user, host FROM mysql.user;检查账号是否允许对应IP访问。
还有一个典型的坑：账号host写的是'localhost'，但应用从另一台机器连进来，MySQL不允许，报Host 'x.x.x.x' is not allowed to connect。这个错误信息已经说得够直白了，去给账号补一个对应网段的权限即可。
6.4 性能突降的应急处理
线上突然变慢，不要急着重启。先做两件事：查慢查询日志和查当前运行中的会话。慢查询日志能告诉你是不是某条SQL突然走错了索引或者扫描行数暴增。当前会话用：
SELECT * FROM information_schema.processlist;看有没有长时间Waiting for table metadata lock或者Lock wait timeout的会话。前者通常是某个事务没提交，把表锁住了，应用侧的写入全堵在后面；后者是并发事务脏读导致的行锁等待超时。遇到长事务，找到源头会话并确认后，可以KILL对应线程ID。但注意，KILL前一定确认是不是业务在跑重要的批处理任务，别把正常作业打断了。
如果是因为缓冲区配置太低导致大量磁盘IO，Innodb_buffer_pool_reads会飙升，平时命中率99%，现在掉到80%以下，这种情况就要考虑调大buffer pool或给实例扩容内存了。
最后的几句实在话
MySQL安装配置这件事，看起来满世界都是教程，但真正值钱的都是细节里那些“没人写”的经验。我自己的习惯是：每装一套环境，就把配置文件和初始化步骤的笔记留档，标注清楚当时为什么这么选，数据目录在哪，备份策略是什么。半年后再回去看，这些记录比任何记忆都靠谱。
最后分享一个小技巧：任何参数改动，先改再测，别一次改一堆。比如调了buffer pool、连接数、日志大小，一次全改，重启后如果性能变差了，你根本定位不了是哪个参数拖的后腿。一次只动一个变量，验证效果，再动下一个。这个习惯救过我很多次，希望你用不上。
