1. 安装之前，必须先想明白的三件事
先把话放前面：MySQL服务安装这个事，本身不难，难的是装完起不来、起来连不上、连上跑不动。我这些年帮人装过太多MySQL，Windows的、Linux的、Docker的，发现问题大多出在装之前没想清楚三件事。你不是在“装一个软件”，你是在决定这个数据库以后怎么被使用。想清楚这三件事，后面所有操作都是顺水推舟。
第一件事：你的业务需要哪个版本？MySQL的版本线大致分成三条——5.7系列、8.0系列、8.4 LTS系列。5.7是曾经的生产主力，现在还在维护期尾巴上，大量老项目还在用；8.0是目前最主流的版本，功能全、性能好，官方持续维护，绝大多数新项目选它没错；8.4是LTS版本，走的是更长的支持周期，适合对稳定性要求极高、不想频繁大版本升级的生产环境。很多人上来就问“哪个版本好”，我一般反问一句：你的业务代码还在用老驱动吗？你的团队熟悉哪个版本？如果都没限制，直接选8.0，别犹豫。5.7只在我明确知道老程序兼容不了8.0的时候才建议用。
第二件事：你的场景是开发环境还是生产环境？如果是本地开发、学习、写demo，怎么省事怎么来，Windows下用ZIP解压版，或者干脆用Docker跑一个容器，几分钟搞定。如果是生产环境，那就得考虑数据目录放哪个盘、用什么方式安装可维护性更好、权限怎么隔离、日志怎么轮转。开发环境的安装教程满天飞，但生产环境需要的是另一套思路——可重复部署、可升级、可回滚。所以后面我会把两种环境的操作分开讲。
第三件事：你的操作系统是什么？Windows下最常见的坑是路径、权限、服务注册；Linux下最常见的坑是仓库配置、data目录初始化、SELinux和防火墙；Docker下最常见的坑是数据持久化和容器网络。同一个MySQL，三种载体，踩的坑完全不是一回事。这篇文章我把三条路都走一遍，你按自己的情况挑着看。
2. Windows平台：解压版才是最适合多数人的路子
2.1 为什么我不建议用MSI安装版
Windows下装MySQL，常见两条路：一是官方提供的MSI安装向导，图形界面一路下一步；二是ZIP解压版，自己初始化、自己配置、自己注册服务。我见过太多人用MSI装完，过两天忘了安装路径，或者装的时候勾了一堆用不上的组件，卸载都卸不干净，最后整个系统环境一团糟。MSI版还有一个问题：它会往注册表里写很多东西，如果你同时装过5.7和8.0，服务名、配置项、环境变量之间很容易打架。
ZIP解压版的好处就一个词：干净。整个MySQL就是一个文件夹，删掉就完事，配置全部写在my.ini里，服务名你也可以自己定。生产环境我几乎不用MSI版，全部是ZIP版手动部署。开发环境更要养成这个习惯，因为你迟早要学会自己管理MySQL的目录结构和配置参数，早学早省事。
提示：ZIP解压版不支持Windows 7及以下系统，官方从8.0开始就只支持Windows 10及以上。如果你的机器还在跑Win7，老老实实用5.7吧。
2.2 下载解压，注意目录别带中文
去MySQL官网的下载页面，选MySQL Community Server，挑ZIP Archive格式，下载体积比MSI小不少。8.0的ZIP包一般在200MB到400MB之间，看具体小版本。解压之后把整个文件夹放到一个干净的位置，比如D:\mysql-8.0.44-winx64。这个地方有个很多人不注意的细节：路径里绝对不能有中文，也尽量不要有空格。MySQL对路径里带中文的容忍度很低，尤其后面初始化data目录的时候，经常报找不到文件或者编码错误，排查起来浪费时间。
解压完成后，你会看到bin、docs、include、lib、share这些子目录，但注意——没有data目录，也没有my.ini。这两个东西都要你自己生成。这也是很多人卡住的第一个坎：解压完直接双击bin里的mysqld.exe，弹个黑框一闪而过，然后一脸懵。
2.3 初始化data目录：两种方式，差别很大
data目录是MySQL真正存放数据库文件的地方，初始化动作会创建系统库（mysql、performance_schema、sys、information_schema）和初始的root账号。初始化的命令是：
cd D:\mysql-8.0.44-winx64\bin mysqld --initialize-insecure--initialize-insecure的含义是：初始化data目录，并且root账号是空密码，没有任何密码。这种方式适合本地开发，后面自己方便登录设置密码。还有一种方式：
mysqld --initialize这个方式会为root生成一个随机密码，并且把这个密码写在日志文件（data目录下的计算机名.err后缀文件）里。第一次启动后你得像寻宝一样去日志里找那一行A temporary password is generated for root@localhost: xxxxxxxx。生产环境我用这个方式，因为不落明文空密码，强制你第一次登录就必须改密码，安全性好很多。
提示：如果你初始化到一半报错，大概率是my.ini还没创建，或者路径问题。ZIP解压版如果没有my.ini，mysqld会使用一组编译时内置的默认参数，初始化路径默认指向当前目录，这时候你必须先进到bin目录里再执行命令。
2.4 写my.ini配置文件，这些参数必须有
在解压目录下新建一个my.ini，内容是最小可用集合：
[mysqld] basedir=D:/mysql-8.0.44-winx64 datadir=D:/mysql-8.0.44-winx64/data port=3306 character-set-server=utf8mb4 default-storage-engine=InnoDB max_connections=200 [client] default-character-set=utf8mb4这里说几个关键点。第一，路径分隔符建议用正斜杠/，MySQL在Windows下对反斜杠\的解析偶尔会出问题，尤其在my.ini里写路径时，反斜杠会被当成转义字符处理。第二，character-set-server必须明确指定，8.0默认已经是utf8mb4，但这个参数写出来是给你自己看的——以后排查中文乱码时，先看这个值。第三，port=3306容易被占，Windows下尤其常见，后面讲到启动报错时细说。
2.5 注册Windows服务和net start报错排查
初始化完成后，用管理员权限打开命令行（不是普通CMD窗口），在bin目录下执行：
mysqld --install MySQL --defaults-file="D:\mysql-8.0.44-winx64\my.ini"这里MySQL是服务名，你可以改成任何名字，比如MySQL80。--defaults-file必须跟在服务名后面，如果你先写--defaults-file再写--install，有时候会被忽略，导致服务启动时找不到配置。
然后启动服务：
net start MySQL如果一切正常，你会看到“MySQL 服务已经启动成功”。但更多人会看到的是“发生系统错误”或者“服务无法启动”。我总结了三个最高频原因：
第一种，data目录没有正确初始化。症状是服务启动后立刻停止，查看Windows事件日志，会看到类似“Can't find data directory”或“MySQL Daemon failed to start”的记录。解决方法是重新执行初始化命令，并且确认my.ini里的datadir和初始化时实际生成的目录一致。
第二种，my.ini里的路径写错了。mysqld服务启动时读取的是注册表里记录的参数路径，如果你改了my.ini的位置或者改完my.ini之后没有重新注册服务，它读的还是老的路径。改配置后，建议先删除服务再重新安装注册一次：mysqld --remove MySQL，再mysqld --install。这一步能省掉70%的启动疑难杂症。
第三种，端口被占用。3306是MySQL默认端口，你的机器上如果之前装过MariaDB，或者开了什么占用端口的服务，就会有冲突。先用这个命令查：
netstat -ano | findstr 3306如果看到有进程PID占用，可以用tasklist查PID对应的进程，确认不是MySQL自己后，要么换端口，要么结束那个进程。
2.6 登录与改密码，密码策略是个坑
服务启动后，用root登录：
mysql -u root -p如果初始化用的是--initialize-insecure，密码直接回车就能进去。进去后第一件事就是改密码：
ALTER USER 'root'@'localhost' IDENTIFIED BY '你的新密码'; FLUSH PRIVILEGES;这里有个容易踩的坑：MySQL 8.0默认启用了validate_password插件，密码强度有最低要求——至少8位，并且要包含大小写字母、数字和特殊字符。如果你设了一个太简单的密码，会直接报错ERROR 1819 (HY000): Your password does not satisfy the current policy requirements。这不是你操作错了，是密码复杂度检查在拦截。如果你只想本地开发用，可以降低策略级别：
SET GLOBAL validate_password.policy = LOW;注意8.0里的变量名带validate_password.前缀，5.7里是validate_password_policy，网上搜到的老资料经常搞混。
3. Linux平台：把MySQL 8.0装进CentOS/Ubuntu的完整链路
3.1 仓库安装还是二进制包安装，怎么选？
Linux下装MySQL，通常有两条大路：用官方Yum/Apt仓库自动安装，或者下载通用二进制包手动部署。仓库安装的好处是省事，一条命令解决安装、依赖、服务注册，以后升级也方便；坏处是你对安装位置、参数文件、数据目录的控制力弱一些，默认路径分散在/etc/my.cnf、/var/lib/mysql、/var/log/mysqld.log这些标准位置。
二进制包手动部署的好处恰恰是控制力强，可以自定义一切路径，适合有规范要求的公司环境，可以把basedir和datadir全部单独分区；坏处是库文件依赖、目录权限、systemd服务文件都要自己处理，像CentOS最小化安装连libaio都没有，缺了这个库mysqld是起不来的。
我的经验是：个人服务器、轻量生产环境，走官方仓库安装；有专有部署规范、或者要装到非标准位置的，走二进制包。下面两条都写。
3.2 CentOS走官方Yum仓库的完整流程
CentOS 7的默认软件源里没有MySQL，只有MariaDB。想用官方源，需要先添加MySQL官方仓库RPM包：
wget https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm rpm -ivh mysql80-community-release-el7-3.noarch.rpm装完这个RPM后，/etc/yum.repos.d/目录下会多出来mysql-community.repo和mysql-community-source.repo两个源文件。默认启用的是8.0仓库。如果你想装5.7，要手动编辑repo文件，把mysql80-community的enabled改为0，把mysql57-community的enabled改为1。这一步很多人漏掉，结果yum install装出来的永远是8.0。
然后安装：
yum install -y mysql-community-server安装完成后，先别急着启动。看一下这几个文件是否存在：
ls -l /etc/my.cnf /var/lib/mysql /var/log/mysqld.log第一次启动前，data目录还是空的，mysqld在启动过程中会自动完成初始化。启动服务：
systemctl start mysqld systemctl status mysqld接下来找初始密码：
grep 'temporary password' /var/log/mysqld.log这行日志会在root账号上生成随机密码，只出现这一次。拿到后用mysql -u root -p登录，按8.0的规矩，第一次登录必须立即修改密码才能执行其他语句。如果日志里没有密码，多半是data目录之前已经被初始化过——比如你从二进制包部署过MySQL，或者上一次卸载没清干净，把/var/lib/mysql残留下来了。
3.3 Ubuntu走APT的方式，和CentOS差异不小
Ubuntu上最省事的命令是apt install mysql-server，但注意——这个命令装的是Ubuntu发行版维护的MySQL，版本跟随系统源，而且很多配置路径跟官方版有区别。比如Ubuntu的MySQL默认配置在/etc/mysql/mysql.conf.d/mysqld.cnf，而不是官方标准的/etc/my.cnf；数据目录同样在/var/lib/mysql，但套接字路径、错误日志位置都重新指定过。如果你后面要参照网上的教程操作，一定要留意是不是同一套目录结构。
如果你希望用官方版MySQL，在Ubuntu上需要先添加官方APT仓库：
wget https://dev.mysql.com/get/mysql-apt-config_0.8.24-1_all.deb dpkg -i mysql-apt-config_0.8.24-1_all.deb这个deb包是个配置向导，会问你选哪个版本，勾选完再apt update，然后apt install mysql-server。Ubuntu上装完，初始密码的查看方式和CentOS一样，看/var/log/mysqld.log。
3.4 Linux安装之后必须做的三件事
安装启动成功只是第一步，有三件事我每次装完必做。
第一件事，执行安全初始化脚本。官方提供了一个快速加固命令：
mysql_secure_installation这个脚本会逐项问你：是否设置root密码强度校验、是否移除匿名用户、是否禁止root远程登录、是否删除test数据库、是否刷新权限表。生产环境全部选yes。其中“禁止root远程登录”这个选择很多人不舍得，但我的建议是：root账号永远只允许localhost登录，应用中需要远程访问的，另外创建专用账号并限制host网段。
第二件事，确认字符集。登录后执行：
SHOW VARIABLES LIKE 'character_set_%';如果看到character_set_server不是utf8mb4，去/etc/my.cnf配置文件的[mysqld]段下加一行：
character-set-server=utf8mb4 collation-server=utf8mb4_0900_ai_ci然后重启服务。字符集这个事，装完不查，等业务上线中文出现????再查，就只能望着数据干瞪眼了。
第三件事，确认开机自启：
systemctl enable mysqld很多人的MySQL跑得好好的，服务器一重启就再也连不上，十有八九是没开自启。
3.5 systemctl无法启动：常见根因与排查路径
写几个我在现场排过的高频故障。
故障一：SELinux拦截。CentOS默认开启SELinux，如果data目录放在非默认位置比如/data/mysql，mysqld进程可能因为访问被拒而启动失败。看一眼SELinux日志怎么查：
ausearch -m avc -ts recent如果确认是SELinux问题，两种解决方式：正规做法是调整策略，semanage fcontext -a -t mysqld_db_t "/data/mysql(/.*)?"然后restorecon -Rv /data/mysql；快刀做法是临时关闭SELinux（生产环境不推荐）。我建议用正规做法，别图省事。
故障二：数据目录权限不对。如果你把datadir改到新路径，需要保证所有者是mysql用户：
chown -R mysql:mysql /data/mysql这条不执行，mysqld启动时会报Permission denied或者Can't create/write to file。
故障三：配置文件里引用了不存在的目录。比如pid-file指定的/var/run/mysqld/mysqld.pid目录不存在。手动创建目录并改所有者就能解决：
mkdir -p /var/run/mysqld chown mysql:mysql /var/run/mysqld故障四：内存不够。MySQL 8.0的innodb_buffer_pool_size默认值比较大，如果服务器内存只有512MB或者1GB，启动时可能因为分配内存失败而退出。处理方式是在配置文件里把innodb_buffer_pool_size调小，比如128M，这个参数决定了InnoDB缓存数据页的内存大小，小内存机器上别用默认值硬扛。
4. Docker部署：适合本地开发，但别忽视三个关键点
4.1 镜像本质：容器的MySQL和本机没有任何关系
很多刚接触Docker的朋友有个误解：docker run mysql:8.0之后，是不是相当于在Windows里装了个MySQL？完全不是。容器里的MySQL跑在一个独立的Linux用户态空间里，它看不到Windows的文件系统（除非挂载），网络端口也是独立的（除非映射），配置文件更是独立的（除非挂载）。理解这个隔离机制，是避免后面一大堆问题的基础。
拉取镜像：
docker pull mysql:8.0提示：
mysql:latest标签现在指向8.x，但锁版本号永远是更稳妥的做法。因为网络上有很多关于“MySQL最新版变了什么”的讨论，实际上用明确版本号（比如mysql:8.0.44）能保证你的开发和部署环境完全一致，不受上游latest变动影响。5.7的有mysql:5.7，8.0的有mysql:8.0，自己按需选择。
4.2 没有数据持久化，容器一删数据全没
这是Docker跑MySQL最大的坑。容器是一个临时层，你docker rm删除容器时，容器内部/var/lib/mysql里的数据会跟着一起消失。解决办法是挂载数据卷：
docker run -d \ --name mysql-dev \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=你的密码 \ -v mysql-data:/var/lib/mysql \ -v /path/to/my.cnf:/etc/mysql/my.cnf \ mysql:8.0-v mysql-data:/var/lib/mysql这里用的是一个命名卷，Docker会把它托管在宿主机的某个目录下，你不需要关心具体路径，销毁重建容器时，后面数据还在。官方镜像还有一个最佳实践：如果你的容器启动失败，或者想换镜像版本，数据卷不删，数据就不会丢。我踩过的一次教训是：本地起了个MySQL练习存储过程，写了半天数据，一时手滑docker rm -f删了容器，没挂卷，数据直接归零。从那以后，不管多简单的测试库，我都挂卷。
4.3 环境变量配置密码、时区、字符集
用官方镜像，可以通过环境变量来初始化：
MYSQL_ROOT_PASSWORD：设置root账号密码MYSQL_DATABASE：自动创建一个数据库MYSQL_USER和MYSQL_PASSWORD：自动创建一个用户并授权给MYSQL_DATABASE
这套机制背后是镜像在首次启动时执行/docker-entrypoint-initdb.d目录里的初始化脚本。注意，只在数据目录为空时生效。如果挂载的卷里已经有数据，这些环境变量不会重复执行。所以别以为改了MYSQL_ROOT_PASSWORD重启容器就能改密码，不会的，那只对首次初始化有意义。
时区和字符集一定要通过启动参数指定，否则容器用的是UTC时间，你查NOW()会差8个小时：
docker run -d \ --name mysql-dev \ -e TZ=Asia/Shanghai \ -e MYSQL_ROOT_PASSWORD=你的密码 \ -p 3306:3306 \ -v mysql-data:/var/lib/mysql \ mysql:8.0 --character-set-server=utf8mb4 --collation-server=utf8mb4_0900_ai_ci容器启动命令后面跟的--character-set-server=utf8mb4，会被透传给mysqld进程。
4.4 容器里的MySQL连不上：端口映射和网络排查
容器跑起来了，日志也正常，宿主机上mysql -h127.0.0.1 -P3306就是连不上，多半是端口映射没生效或者防火墙挡了。先看容器端口情况：
docker port mysql-dev正常会显示3306/tcp -> 0.0.0.0:3306。如果没有，说明-p参数没写对。再确认宿主机的防火墙，CentOS的firewalld、Windows的入站规则，都要放行3306端口。如果宿主机没放行，容器端口映射做得再对，外部也连不进来。
还有一类场景：你不是在宿主机上连，而是容器外、同一网络其他机器连。这时候-h的地址写宿主机的IP，不是容器IP。如果你看到Access denied，那是认证问题；如果看到Can't connect through socket或者Unknown MySQL server host，那是网络问题，别混在一起排查。
提示：
docker run有个--network=host模式，Linux下可以直接使用宿主机网络，省去端口映射，但Windows和macOS上这个模式是无效的，你该映射还是得映射。
4.5 docker pull mysql失败的常见原因
很多人卡在第一步：docker pull mysql:8.0失败。最常见的原因依次是：Docker daemon没启动、网络连不上镜像仓库、镜像仓库地址配置问题、磁盘空间不足。排查路径看一眼docker info确认daemon状态，再看磁盘df -h确认空间，然后ping一下镜像服务器的域名确认网络连通性。确认网络没问题的情况下，更多是镜像仓配置的问题，检查你的Docker配置文件里的仓库地址，换成可用地址再systemctl restart docker。这里要提醒一句：由于网络环境差异，全球不同地区访问同一镜像仓库的顺畅程度差别很大，遇到拉取失败时，优先检查本地网络和服务状态，不要急着猜测是镜像的问题。
5. 安装完不等于结束：这些高频报错，几乎人人会碰到
5.1 “服务无法启动”的底层思路：先看日志，再动手
排查MySQL启动问题，我的习惯永远是：先看日志，再动手改配置。MySQL的错误日志是排错的唯一权威信息源。Windows下日志在data目录下的计算机名.err文件里；Linux下默认在/var/log/mysqld.log；Docker下用docker logs 容器名。日志不是用来“瞄一眼”的，要重点看最后面几十行，定位带[ERROR]字样的内容。
举一个真实例子。有人启动时遇到[ERROR] [MY-010584] Can't create/write to file '/var/run/mysqld/mysqld.pid'，错误的原因在上面写过，/var/run/mysqld目录不存在。但如果你不看日志，会瞎猜一堆原因，浪费时间。日志会直接告诉你缺了哪个文件，缺了哪个目录，访问不了哪个路径。所有MySQL权威文档里都写着“检查错误日志”这一条，实际操作中却总被人跳过。
5.2 root默认密码和第一次登录的密码陷阱
装完MySQL之后，第一次登录凭据永远是两个方向中的一种：要么是空密码（--initialize-insecure初始化），要么是随机生成的临时密码（--initialize初始化或者Linux仓库安装）。不要去试什么“123456”“root”这类弱密码，5.7及以上版本默认就不会生成这些弱密码作为初始值。
临时密码在日志里的位置要找准。Linux下是grep 'temporary password' /var/log/mysqld.log，Windows下要打开data目录下的.err文件搜索temporary password。拿到临时密码登录后，任何第一次操作都会遇到提示You must reset your password using ALTER USER statement before executing this statement.——这不是报错，是安全机制，你要在确认没有别的语句挂起的情况下，第一时间执行：
ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';密码改完，后续操作才能继续。这个阶段还有个容易犯的错误：MySQL 8.0默认使用caching_sha2_password插件，而很多老版本客户端（比如一些图形化工具的老版本）不支持这个认证方式，报错信息类似Authentication plugin 'caching_sha2_password' cannot be loaded。遇到这种情况，要么升级客户端，要么在MySQL里把账号认证方式改回mysql_native_password：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';5.3 远程连不上：别急着怪防火墙，先看root的host限制
本地登录一切正常，但远程客户端连不上，这类问题的黄金排查顺序是：先确认网络通不通（ping目标机器IP），再确认端口通不通（telnet或nc测试3306），最后确认MySQL账号是否允许这个来源IP连接。
默认情况下，root账号的host是localhost，就只能本机连。你需要在MySQL里创建一个允许远程连接的业务账号，而不是尝试给root放开所有来源。安全习惯要从第一天养成：
CREATE USER 'app_user'@'192.168.%.%' IDENTIFIED BY '强密码'; GRANT ALL PRIVILEGES ON mydb.* TO 'app_user'@'192.168.%.%'; FLUSH PRIVILEGES;关于MySQL的or（OR关键字）能否去重这个问题，实际上是一个经典的SQL理解误区——OR是逻辑或，不是去重关键字，去重只能用DISTINCT或者GROUP BY。这类SQL基本功问题在安装完成后的一段时间里会集中涌现，等你开始写业务代码时自然会碰到。
5.4 SSL连接错误：看着吓人，多数是个配置问题
MySQL 8.0默认启用了SSL连接，如果客户端和服务器端的SSL配置不一致，会出现ERROR 2026 (HY000): SSL connection error。网上大量教程会让你直接关掉SSL，--skip_ssl，但不建议一上来就关。先检查服务端SSL状态：
SHOW VARIABLES LIKE '%ssl%';have_ssl是YES，说明SSL开启。客户端连接时加--ssl-mode=DISABLED可以绕过，但这只是排查手段。如果你的应用确实不需要SSL加密（比如纯内网环境），才考虑在服务端配置skip_ssl。生产环境尽量保留加密连接，哪怕麻烦一点。
还有一种特殊情况：使用Docker部署后，容器里的MySQL SSL证书默认用的是镜像自带的，如果你把数据目录挂载出去之后重新初始化，可能导致证书文件找不到。报错会形如[ERROR] [MY-014060] [Server] Invalid MySQL server upgrade。这类升级和证书问题，先检查挂载目录里有没有保留之前的auto.cnf和证书文件，备份再处理。
5.5 运行库缺失：Windows下的ODBC依赖问题
Windows上如果你用ODBC连接MySQL，会发现需要一个叫MySQL ODBC Driver的组件。这个驱动本身安装很顺利，但连接时经常报错“找不到指定的模块”或者“无法加载驱动”，这时候别怀疑是ODBC Driver版本问题——极大概率是你的机器缺了Microsoft Visual C++ 2015 Redistributable运行库。MySQL 8.0的ODBC驱动编译时依赖VC++ 2015-2019运行库，而很多精简版Windows、刚装好的干净系统根本没有这个公共组件。去微软官网下载Visual C++ Redistributable for Visual Studio 2015-2022，装完重启，问题往往直接消失。
这个坑特别隐蔽，因为报错提示完全不提VC++，只说ODBC驱动加载失败。我现场帮人排查过至少三回，前两回还在纠结ODBC驱动要不要换版本，第三回才意识到是运行库的问题。顺便说一句，mysqld.exe启动时如果提示VCRUNTIME140.dll 找不到，同样是这个原因。
6. 不同场景下的安装路径选择，我的最终建议
看到这里，三条路都走完了。最后说说我个人的选择逻辑。
本地开发、想快速验证、不想污染Windows系统环境，首选Docker。一条docker run命令搞定，删了重建毫无负担，镜像版本还可以随官方更新。前提是你的机器装了Docker Desktop，并且内存至少给它留4GB。
公司Windows办公机、需要长期运行本地服务、并且希望开机自启，选ZIP解压版注册Windows服务。这比Docker的方案更“原生”，不依赖Docker Desktop这个额外的中间层，资源占用也更可控。缺点是升级麻烦一点，要手动替换目录文件、保留数据目录。
生产环境跑Linux服务器，选官方仓库安装。理由很简单：升级方便（yum/apt一条命令）、systemd集成完善、目录标准统一——后续的运维监控、日志收集、备份脚本，都基于这些标准路径。如果公司有特殊的安全基线要求，再换二进制包手动部署，那是另一套精细活。
至于版本，我再重复一次：新项目一律8.0，老项目维持原版本（5.7还有余量，但尽早规划升级8.4 LTS或者8.0）。不要在生产环境追求“尝鲜”，也不要因为“习惯”死守老版本。MySQL从5.7到8.0的跳跃，改了很多底层行为——排序规则默认值变了（utf8mb4_general_ci到utf8mb4_0900_ai_ci）、认证插件变了（mysql_native_password到caching_sha2_password）、部分语法和参数名称也调整了。这些变化是升级时的痛点，但从8.0再往后的LTS版本，兼容性好得多。
最后分享一个我的习惯：每次装完MySQL，我会顺手写一个install_notes.txt，记录安装日期、版本号、安装路径、数据目录、端口号、配置文件的修改点。看起来是小事，但半年后你回来看自己装的实例时，这份笔记的价值会非常大——尤其是当你同时维护好几台服务器和好几个容器的时候。装MySQL从来不是“下一步下一步”的事，而是你对自己数据库环境的一份清晰记录和掌控。把基础打好，后面写SQL、调性能、做备份，都会顺畅得多。
