在CentOS 7上装MySQL 8.0，我见过太多人在这一步卡住。有的卡在依赖报错，有的卡在找不到临时密码，还有的干脆不知道官方仓库这回事，直接去下载了个乱七八糟的源码包自己编译，结果编译到一半就开始怀疑人生。实际上，只要把安装源和初始化密码这两个关键点理顺，整个安装过程二十分钟内肯定能走完。这篇博文会从CentOS 7和MySQL 8.0之间的版本差异讲起，把从配置Yum源到完成基本安全设置的完整过程一步一步拆开，适合刚接触Linux运维的同学，也适合那些在虚拟机上练手、准备从MySQL 5.7往8.0迁移的兄弟参考。
1. CentOS 7与MySQL 8.0的组合：先看清三个"版本错位"
很多人装MySQL 8.0失败，不是操作步骤有问题，而是根本没意识到CentOS 7这套系统里藏着好几个"版本错位"的坑。把这些错位提前弄清楚，后面每一步都会顺畅很多。
1.1 自带MariaDB的尴尬：默认源里其实没有MySQL 8.0
CentOS 7默认的软件仓库里，数据库这块默认装的是MariaDB，而不是MySQL。即使你在系统里执行yum install mysql，装上的也只是MariaDB兼容的分支版本，并不是真正的MySQL。这是第一个让人迷惑的地方：你以为自己装了MySQL，实际上装了个长得像MySQL的MariaDB。
就算你手动去把官方源里MySQL 5.7相关的包装上，CentOS 7默认源提供的MySQL相关组件版本也普遍偏旧，和8.0差了整整一个大的时代。8.0里像窗口函数、CTE公共表表达式、降序索引这些特性，旧版本一概没有。所以，如果你手里有一套想要依赖MySQL 8.0新特性的业务代码，或者就是想用新版本的性能优化，靠系统自带源是搞不定的。
我的建议是，在CentOS 7上安装MySQL 8.0，第一步就是明确一个概念：必须单独配置MySQL官方的Yum仓库，而不是指望系统默认的base或epel源。官方仓库里对MySQL 8.0的开头是mysql80-community，这一点后面会详细说。
1.2 兼容性保障：CentOS 7与MySQL 8.0的组合本身没问题
有些人听到MySQL 8.0是2018年发布的，CentOS 7是2014年的系统，就会担心年代跨度太大，兼容性有问题。实际上这个顾虑基本可以放下。MySQL官方发布的Linux通用版和Yum仓库版，都是针对主流Linux发行版做过适配的，CentOS 7作为Red Hat 7的兼容版本，属于官方重点支持对象。在官方的Yum仓库页面里，明确提供了对应的el7版本rpm包，这就是给CentOS 7这种RHEL 7系操作系统准备的。
不过有一个点必须提醒：CentOS 7上的glibc、libaio、ncurses这些基础库版本相对老，而MySQL 8.0的二进制包对它们有一定的版本要求。绝大多数情况下，直接通过Yum官方仓库安装会自动解决这些依赖问题，这也是我强烈推荐用Yum而不是自己去下载.tar.gz源码包编译的原因。你自己手动编译或者用二进制包时，才会频繁遇到libncurses.so.5缺失、libaio找不到这类麻烦。
1.3 官方Yum仓库与二进制包怎么选
在实际安装方式上，我见过的主要有三种：源码包编译、官方二进制包解压配置、官方Yum仓库安装。这里直接给结论，省得大家浪费时间。
| 安装方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 官方Yum仓库安装 | 依赖自动处理，升级方便，卸载干净 | 版本由仓库决定，自定义编译参数受限 | 绝大多数生产环境和学习环境，强烈推荐 |
| 官方二进制包（tar.gz） | 目录可控，适合离线内网环境 | 依赖库容易缺失，需要手动初始化数据目录 | 内网离线部署、对安装路径有特殊要求 |
| 源码包编译 | 可深度定制编译选项 | 耗时长，依赖gcc、cmake等一堆工具，出错的概率最高 | 极少见，非特殊性能要求不建议 |
我自己在虚拟机和云服务器上安装MySQL 8.0时，基本都是走官方Yum仓库这条路。省掉依赖地狱不说，后续yum update还能直接升级MySQL的小版本，这对日常维护来说太省心了。如果你看到网上一些教程还在让你去MySQL官网手动下载mysql-8.0.xx-linux-glibc2.12-x86_64.tar.xz再解压配置，也不是不行，但明显绕了一条远路。
2. 安装前的环境准备：找对仓库源，后续少折腾
安装之前先把系统环境摸清楚，磨刀不误砍柴工。这一步做得好，后面基本上就是一路Next的顺畅感。
2.1 用配置文件确认系统版本和残留软件
在虚拟机或者云主机上登录系统后，我习惯先看一下系统版本，确认自己操作的确实是一个纯净的CentOS 7环境。
cat /etc/redhat-release # 输出示例：CentOS Linux release 7.9.2009 (Core)接着检查系统里是否已经存在MySQL或者MariaDB的相关残留，这一步很多人会跳过，但跳过之后踩坑的概率极高。尤其是那些按教程装过一半、装到一半放弃的机器，残留的配置文件和数据目录会跟新装的MySQL 8.0打架。
rpm -qa | grep -E 'mysql|mariadb' systemctl status mysqld如果有旧的MariaDB在运行，需要先停掉服务再做卸载，不然Yum安装时会出现文件冲突：安装包要往/usr/bin/mysql之类的路径写文件，结果位置被旧程序占着，直接报错。本机如果没有任何输出，说明环境干净，可以放心往下走。
2.2 下载并安装MySQL官方Yum仓库RPM
MySQL官方为了简化安装流程，准备了一个仓库安装包，这个东西本身是一个很小的rpm文件，装上它之后系统就自动多出了几个仓库源：mysql80-community、mysql57-community等。我们要做的就是下载这个rpm并安装。
wget https://repo.mysql.com/mysql80-community-release-el7.rpm rpm -ivh mysql80-community-release-el7.rpm如果没有wget，可以用curl -O代替，或者先yum install -y wget安装一下。rpm -ivh执行完后，可以检查一下仓库是否已经被系统识别：
yum repolist all | grep mysql正常情况下会看到mysql80-community/x86_64这一行，且状态为enabled。如果看到mysql57-community和mysql80-community都是enabled的状态，那就需要用yum-config-manager工具来调整默认启用的版本，确保只启用8.0，否则Yum在安装时可能默认去装5.7。
yum-config-manager --disable mysql57-community yum-config-manager --enable mysql80-community这段操作本身就是个很容易踩的细节：同时启用两个版本的MySQL源，最终装出来的版本不一定是你心里想的那个。多花十秒钟检查，能省掉后面一小时的排查时间。
2.3 检查仓库状态并处理模块冲突
CentOS 7的Yum仓库有一个特殊的模块机制，虽然CentOS 7本身对AppStream模块的支持不如CentOS 8那么强，但还是要注意一下。特别是如果机器上之前装过其他数据库，可能存在模块流冲突。处理方式比较简单，直接执行：
yum module disable mysql如果系统提示没有这个模块，说明当前仓库列表里没有定义，不影响继续安装。这一步的目的是把那些可能导致mysql组件的模块干扰排除掉。接着再做一次仓库刷新：
yum clean all yum makecache这样Yum的缓存就是干净的，后面install的操作会从正确的源里拉取8.0相关的包，不会出现原本想装8.0、结果Yum提示软件包不存在，或者装出一个不认识的版本号这种情况。
到这里，环境准备阶段就完成了。整个过程的核心思路很简单：让系统里只有一个启用的MySQL官方源，且这个源对应的版本是8.0。把这个前提固定住，安装过程本身反而没那么容易出错。
3. 正式安装与首次启动：命令不多，细节不少
环境准备完成之后，真正的安装步骤其实只有几条命令，但每条命令背后的机制值得搞清楚，不然出问题的时候一脸懵。
3.1 用Yum安装mysql-community-server，顺带说下依赖
执行下面这条命令，系统就会自动从mysql80-community这个仓库拉取并安装MySQL 8.0：
yum install -y mysql-community-server安装过程中Yum会下载好几个包，mysql-community-server、mysql-community-client、mysql-community-libs、mysql-community-common等，它们之间有着严格的依赖关系。有些人以为装一个server包就够了，其实client和libs这些是server运行的基础依赖，Yum会自动处理。
还有一个依赖值得一提：mysql-community-libs和系统自带的mariadb-libs会冲突。如果前面检查阶段没有卸载MariaDB的相关包，这里就会直接报错，提示file /usr/share/mysql/charsets/... conflicts。解决办法是先卸载mariadb-libs：
yum remove -y mariadb-libs卸载MariaDB依赖库时要留意，有些软件包可能依赖它，但绝大多数情况下影响不大。卸载之后再执行一遍安装命令就能正常走完。如果装的过程中出现libaio.so.1()(64bit) is needed这种报错，说明系统里缺libaio库，安装一下就好：
yum install -y libaio yum install -y ncurses-compat-libsncurses-compat-libs经常被忽略，但MySQL 8.0里部分命令行工具在CentOS 7这种老版本系统上需要它来补齐ncurses版本兼容。把这些依赖装齐，安装过程才会百分百顺利。
3.2 启动服务的正确姿势：systemd日志与临时密码
安装完成后先别急着登录，先把服务启动起来。MySQL 8.0在CentOS 7上是通过systemd来管理的，所以启动命令是：
systemctl start mysqld systemctl enable mysqldenable是为了设置开机自启，这个建议在安装后立刻做，避免服务器重启之后MySQL没起来，业务方半夜找你麻烦。启动之后用下面几条命令确认状态：
systemctl status mysqld ss -tlnp | grep 3306看到active (running)并且3306端口在监听，说明服务已经正常起来了。这一步如果出问题，最常见的原因就是数据目录/var/lib/mysql的权限不对，或者配置文件的语法有问题。可以直接查看MySQL的错误日志来定位：
tail -n 50 /var/log/mysqld.log这里要特别强调一下MySQL 8.0的一个新特性：在首次启动时，mysqld会自动执行数据目录的初始化，并且在日志文件里生成一个临时的root密码。这个临时密码是安装完成后连接数据库的唯一凭证，很多人第一次就没找到它。查看方法：
grep 'temporary password' /var/log/mysqld.log日志里会输出类似root@localhost: xxxxxxxx的内容，这一串就是初始密码，建议立刻复制保存。如果日志里搜不到，可能是因为之前手动初始化过数据目录，或者日志已经被清空。这种情况可以将MySQL停掉，删除重新初始化数据目录后再启动，但前提是目录里没有重要数据。
3.3 第一次登录：密码过期与必须立刻改密
拿到临时密码后，用MySQL客户端登录：
mysql -uroot -p输入临时密码后，你会进入MySQL的命令行。但先别急着高兴——在MySQL 8.0里，初始的root账号处于密码过期状态，你想执行任何正常的SQL都会被告知必须先修改密码。这是8.0默认的密码安全策略，和5.7时代的体验不一样。
执行修改密码的语句：
ALTER USER 'root'@'localhost' IDENTIFIED BY '你的新密码';这里有个非常典型的坑：MySQL 8.0默认启用了validate_password组件，对密码强度有要求。最低策略下密码也至少要8位，并且包含数字、大小写字母、特殊字符中的至少三类。如果设置的密码强度不够，会直接报错ERROR 1819 (HY000): Your password does not satisfy the current policy requirements。
如果只是想在自己的虚拟机上学习，不想被这些安全策略搞得太麻烦，可以把密码策略调低：
SHOW VARIABLES LIKE 'validate_password%'; SET GLOBAL validate_password.policy = LOW; SET GLOBAL validate_password.length = 6;需要注意，SET GLOBAL在重启后会失效，如果想让配置持久化，需要把它写进/etc/my.cnf的[mysqld]段里。不过在生产环境，我还是建议保留默认的强密码策略，毕竟数据库裸奔五分钟，风险就不可控了。
到这里，MySQL 8.0的本体已经能正常登录使用了。但从能用到好用，中间还差着几项关键配置。
4. 初始化配置：密码策略、远程访问与字符集三件事
装好了数据库，接下来要面对的是三件绕不开的事：密码改好之后怎么管理、远程怎么连接、中文乱码怎么避免。这三件事直接决定了这个数据库能不能真正投入项目使用。
4.1 修改root密码并理解validate_password的规则
严格来说，前面已经通过ALTER USER把临时密码改成了自己的密码。但如果你只是想改得简单点，比如开发环境用123456这种，就会被密码策略拦住。原因在于MySQL 8.0的validate_password组件默认开始介入，而CentOS 7上的这款应用默认策略是MEDIUM，需要满足长度和字符组合要求。
我建议的正规流程是这样的：先用一条强密码把密码改了，再根据实际安全需求调整策略。先改强密码，保证数据库可用；然后再评估自己的使用场景，决定要不要把策略调低。如果你在一个真实的项目环境里，root用户的密码管理还应该建立定期更换机制，并且最好用专门的账号给业务使用，而不是所有程序都直连root。
另外，MySQL 8.0的用户认证插件默认是caching_sha2_password，这个插件的密码传输和验证方式比5.7时代的mysql_native_password更安全。但它的副作用是，一些老版本的客户端工具（例如老版本的Navicat、PHP老版本中的mysql扩展）会连不上，这个我们放到后面踩坑部分细说。现在只需要记得：新装的MySQL 8.0，root账号默认用的是新认证插件。
4.2 开启远程访问：用户授权与防火墙放行
默认情况下，MySQL的root账号只允许从本地连接，也就是root'@'localhost'。如果你需要从自己的电脑上通过Navicat、DataGrip这类工具连接服务器上的MySQL，就得先创建一个允许远程连接的账号，并给它授权。
在MySQL命令行里执行：
CREATE USER 'dev'@'%' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON *.* TO 'dev'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;这里的'dev'@'%'表示任意来源IP都能用dev账号连接。如果想限制来源，可以把%换成具体的IP或网段，比如'dev'@'192.168.1.0/24'，这在生产环境里是必做的安全设置，千万不要图省事。
账号建好之后还有一道防火墙关卡。CentOS 7默认是用firewalld管理防火墙，如果没放行3306端口，外部连接会被直接拒绝。放行方法：
firewall-cmd --permanent --add-port=3306/tcp firewall-cmd --reload同时要确认SELinux没有拦截MySQL的网络访问。CentOS 7默认SELinux是 enforcing 状态，有时候即使防火墙放行了，SELinux依然会挡。简单排查方式是把SELinux临时设为permissive模式再试一次：
setenforce 0如果设置成permissive之后远程连接就通了，那说明SELinux的策略需要调整，或者干脆你就把它继续保持宽松模式。但在生产环境，我推荐用setsebool -P mysqld_connect_any=1这种精确调节的方式，而不是一刀切关闭SELinux。
4.3 把字符集切成utf8mb4，避免中文乱码
MySQL 8.0默认字符集其实已经比5.7时代进步不少，但CentOS 7上安装后默认值依然是latin1或者utf8mb4取决于具体版本和初始化参数。有个概念必须澄清：utf8在MySQL里最多只能存3字节的字符，遇到emoji表情这类4字节字符就直接存不进去，只有utf8mb4才能完整覆盖。所以现在所有正规项目都应该用utf8mb4。
在修改配置之前，先看一下当前的值：
SHOW VARIABLES LIKE 'character_set%';如果character_set_server不是utf8mb4，就需要修改/etc/my.cnf。打开这个配置文件，在[mysqld]段下追加：
[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_0900_ai_ci在MySQL 8.0里，默认的collation推荐用utf8mb4_0900_ai_ci，这是8.0新增的排序规则。如果想要兼容旧业务的排序习惯，也可以设置成utf8mb4_unicode_ci。改完之后重启MySQL让配置生效：
systemctl restart mysqld重启后再次查看字符集变量，确认character_set_server变成了utf8mb4即可。另外，针对已有的数据库或表，如果建库时用了别的字符集，需要单独执行ALTER DATABASE或ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4来转换，这部分在新建表的时候提前规划好，能省掉后续迁移的大麻烦。
4.4 设置开机自启，以及一个关于my.cnf的提醒
关于开机自启，前面已经执行过systemctl enable mysqld。这里再补一个检查命令，确认enable状态确实是生效的：
systemctl is-enabled mysqld如果输出enabled，说明服务会随系统自动启动。systemctl enable这个命令在CentOS 7上，本质上只是创建了一个符号链接到/etc/systemd/system/multi-user.target.wants/目录。如果哪天你发现重启后MySQL没起来，先检查这个符号链接是不是被误删了，再看/etc/my.cnf有没有语法错误。
这里要专门提醒一下：/etc/my.cnf在CentOS 7上对MySQL 8.0而言是最核心的配置文件。很多人在里面写了乱七八糟的skip-grant-tables来绕过密码修改，或者在[mysqld]段里写了一些5.7时代的旧参数（比如innodb_file_format），这些在8.0里要么被移除要么被废弃，轻则报错，重则服务起不来。正确做法是，修改配置前先备份一份，然后每次只改一项，改完重启验证，这样即使出问题也能快速定位。
5. 踩坑实录：四个典型的安装失败现场与排查链路
这里把我在实际环境中遇到最多的几个安装类问题整理出来，每个都给出排查思路，而不是直接甩解决方案。这样你下次遇到类似问题，至少知道该怎么一步步往下查。
5.1 依赖缺失：libaio和libncurses的尴尬
报错现场是这样的：执行yum install mysql-community-server后，Yum直接报错：
Error: Package: mysql-community-server-8.0.xx-1.el7.x86_64 (mysql80-community) Requires: libaio.so.1()(64bit)这是典型的依赖未满足，问题在于你的系统里缺少MySQL需要的动态库。为什么Yum没有自动解决？因为libaio库在CentOS 7的base源里是有的，但如果你在安装时用了--skip-broken或者某个源的优先级把base源屏蔽了，依赖解析就会出问题。
排查链路：先确认系统里有没有这个库，用ldconfig -p | grep libaio查看。没有就去安装yum install -y libaio，装完再重跑MySQL的安装命令。同理，libncurses.so.5缺失时，要装的是ncurses-compat-libs这个包，因为它提供了老版本的libncurses库。
这种问题本质上是CentOS 7和MySQL 8.0的库版本差异引起的，只要你肯多花一分钟把依赖库补齐，接下来安装就一路畅通。
5.2 socket连不上：先分清数据目录和日志
另一个高频报错是：
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)这个报错的意思是客户端通过socket文件连不上mysqld，本质原因要么是服务没起来，要么是socket文件路径配置不一致。排查链路比报错本身重要。
第一步，先看服务到底跑没跑：
systemctl status mysqld ps -ef | grep mysqld如果服务根本没起来，问题就变成了"为什么起不来"，去/var/log/mysqld.log看错误日志。常见原因包括：/var/lib/mysql目录权限不对，或者之前异常断电导致数据文件损坏。如果是权限问题，执行：
chown -R mysql:mysql /var/lib/mysql如果服务已经起来了但客户端还是报socket错误，那就是路径不一致导致的。检查/etc/my.cnf里有没有指定socket路径，客户端连接时也可以显式指定：
mysql -uroot -p --socket=/var/lib/mysql/mysql.sock另外，通过ss -tlnp | grep 3306能看到端口监听状态，远程连接排查用端口，本机连接常见用socket，这个顺序理清楚，排查这类报错会快很多。
5.3 老客户端连不上：caching_sha2_password带来的兼容问题
MySQL 8.0发布到现在，依然有一个非常普遍的坑：你在服务器上用命令行连接一切正常，但用Navicat 11、Python 2.7的旧MySQLdb库或者老版本JDBC驱动连接时，直接报错：
Authentication plugin 'caching_sha2_password' cannot be loaded这正是因为MySQL 8.0默认的认证插件是caching_sha2_password，而老客户端不认识这种新插件。解决办法有三种：
第一种，修改用户的认证插件为旧版mysql_native_password：
ALTER USER 'dev'@'%' IDENTIFIED WITH mysql_native_password BY '你的密码';第二种，如果不想改旧插件，就升级所有客户端到支持caching_sha2_password的版本。现代版本的Navicat、MySQL Workbench、较新的JDBC驱动都已经支持了。
第三种，在配置里设置default_authentication_plugin = mysql_native_password，让新建用户默认使用旧插件。但这样会牺牲新特性的安全性，只推荐用于内网低敏环境。
我自己在实际项目中的选择是：本机命令行和现代客户端，继续用默认的caching_sha2_password；那些跑老业务的、一时没法升级的客户端连接，单独为它们创建专门的账号并指定mysql_native_password。这样两头都保住。
5.4 旧版MariaDB残留导致的仓库冲突
之前提到过mariadb-libs和MySQL安装包冲突的问题，这里展开说一下完整的排查链路。执行Yum安装时报错：
file /usr/share/mysql/charsets/Index.xml from install of mysql-community-server-8.0.xx conflicts with file from package mariadb-libs-1:5.5.xx-1.el7.x86_64这个意思很直白：新装的文件和旧版MariaDB的文件撞了。为什么会有mariadb-libs？因为CentOS 7本身默认装了MariaDB相关的库，哪怕你的机器上并没有开启任何MariaDB服务，基础依赖里也带着它。
处理办法也直白：把mariadb-libs卸掉。卸载前可以确认一下有没有正依赖它的服务：
rpm -q mariadb-libs yum remove -y mariadb-libs卸载完成后重新执行MySQL安装命令，文件冲突自然消失。如果你的机器上有已经在跑的业务用了MariaDB，那就得先做数据迁移而不是直接卸载，这个情况和干净安装是两码事。
5.5 升级时的一个通用排查思路
还有一类场景：你的机器上原本已经装了MySQL 5.7，现在想把数据迁到8.0，直接执行Yum升级却不成功。这里要注意，MySQL 8.0和5.7之间有很多不兼容的变更，官方建议是逻辑升级：先用5.7的mysqldump把数据导出成SQL文件，装好8.0后再导入。我见到有人直接yum update把5.7升级到8.0的，结果数据字典不兼容、认证插件不兼容，问题一堆。
升级的排查链路应该是：先备份数据，然后停掉5.7服务，卸载5.7的包，再按本文的流程装8.0，最后导入备份。所以如果遇到升级失败，别急着改配置硬刚，退一步，按这个链路重新走一遍，反而更省事。
6. 安装完成后的验证与日常维护
服务跑起来之后，别急着下班。我把最后的验证步骤和维护习惯写完整，这套做完才算真正搞定。
6.1 快速验证：版本号、服务状态、连接情况
执行下面这一组命令，基本能在三十秒内判断数据库是否健康：
mysql --version systemctl status mysqld mysqladmin -uroot -p status ss -tlnp | grep 3306mysql --version会输出类似mysql Ver 8.0.xx for Linux on x86_64的版本信息，确认安装的就是8.0。mysqladmin status返回的信息里能看到Uptime、Threads、Questions这些核心指标，如果Uptime持续累计，说明服务稳定。端口监听检查则确认了网络层的正常。
还要顺手验证一下远程连接是否真的通了。在自己的电脑上用MySQL客户端或者telnet试一下端口：
telnet 服务器IP 3306如果看到Connected to 服务器IP，说明网络链路已经通。这时候再用图形化工具连一下，全链路就完全验证完毕了。
6.2 一台生产服务器的基本维护清单
我个人维护MySQL服务器的习惯里，有下面这几件事是每周必做的，在这里也分享给你作为参考：
第一，查看错误日志。tail -n 200 /var/log/mysqld.log，重点关注有没有报错级别的记录，尤其是关于InnoDB的警告。InnoDB在MySQL 8.0里是默认存储引擎，它的日志信息非常值得关注。
第二，检查连接数和慢查询。SHOW PROCESSLIST;和SHOW GLOBAL STATUS LIKE 'Slow_queries';，如果发现慢查询数量增长明显，就要去分析慢查询日志了。可以在my.cnf里开启：
slow_query_log=1 slow_query_log_file=/var/log/mysql-slow.log long_query_time=2第三，做备份。mysqldump是官方自带的全量备份工具，简单可靠的备份命令：
mysqldump -uroot -p --all-databases --single-transaction --routines --events > /backup/all_$(date +%F).sql--single-transaction能保证InnoDB表备份时的一致性，--routines和--events会把存储过程和事件一起备份下来。在8.0里，建议用--set-gtid-purged=OFF来避免导入时的GTID信息冲突，具体看你的环境是否开启了GTID。
6.3 安装维护中我坚持的几个习惯
最后聊聊我踩过多次坑之后总结出的几个习惯，希望能帮你少走点弯路。
第一个习惯是改配置之前一定先备份。cp /etc/my.cnf /etc/my.cnf.bak只需要一秒钟，但能在你改错配置之后救你一命。每次修改只改一个参数，改完重启，再用业务侧测试连接，有问题就能立刻知道是刚才那次改动引起的。
第二个习惯是监控磁盘空间。MySQL的数据目录默认在/var/lib/mysql，很多云服务器根分区只有20G甚至10G，一支innodb的redo日志就能吃掉几G空间。建议用df -h /var/lib/mysql定期检查，如果空间快满了，优先清理binlog日志：PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;，而不是直接删文件。直接删binlog文件会让系统找不到对应的index记录，反而出问题。
第三个习惯是不要混用多个Yum源。CentOS 7上除了MySQL官方源，还有epel和base源，如果某个第三方源里也带了MySQL相关的包，Yum解析依赖时可能装上奇怪的版本。保持源简洁，装数据库之前先yum repolist看清楚，是保证环境稳定的大前提。
我在帮朋友排障时发现，最终折腾到半夜的问题，往往不是安装步骤的问题，而是某些看似无关紧要的习惯性操作带来的副作用。把数据库最基本的安装和初始化做扎实，后续的维护成本真的会低非常多。希望这篇内容能让你在CentOS 7上装MySQL 8.0时少走几次弯路。
