★ FEATURED ARTICLE 在 macOS 上装 MySQL 5.7按理说是个老生常谈的问题但我发现网上大量教程要么过时、要么写得云里雾里尤其是现在 Apple Silicon 芯片普及之后很多旧教程里的操作直接就跑不通。我最近刚在一台 Mac mini 上给某个存量项目搭了一套 MySQL 5.7 环境中间踩了几个不大不小的坑。这篇文章就把整个过程重新梳理一遍包含完整可复现的命令、参数解释和排查思路给你一条尽量顺滑的安装路径。先说清楚一件事现在 MySQL 官方已经不再对 5.7 做新的功能更新社区主推 8.0那为什么还要装 5.7最大的原因是存量业务。很多公司的线上库还跑在 5.7或者某些老系统的 SQL 语句依赖 5.7 的查询优化器行为直接升 8.0 会出现慢查询、兼容性报错。还有就是本地开发环境必须跟生产保持一致否则你在本地测得好好的一上生产就翻车。所以“在 macOS 上装一个 MySQL 5.7”看起来简单但涉及版本选择、安装方式、连接驱动、字符集、权限模型等一连串问题任何一个环节不对后面写代码的时候就会被各种奇怪的问题折磨。这篇文章主要面向两类人一类是刚接触 MySQL需要在 Mac 上搭一个本地开发库的初学者另一类是负责维护存量项目、被迫在本地跑 5.7 的开发者。我会把 Homebrew 安装方式、初始化流程、常见坑和排查手段都过一遍。如果你之前装过 MySQL 8.0 或者其他版本本文里的清理操作对你也一样有用。1. 安装方案选型为什么我推荐 HomebrewmacOS 下装 MySQL 5.7主流路子大概就三条官方 DMG 安装包、Homebrew 包管理器、Docker 容器。我个人的建议是能用 Homebrew 就优先 Homebrew。官方 DMG 的方式双击安装向导一路下一步看似省心。但问题在于 DMG 安装的 MySQL 会注册成一个 launchd 服务默认开机自启而且安装路径、配置文件的组织方式和命令行工具链的集成都比较“自成一体”。比如你系统里原本用 brew 管理 PHP、Python 这些工具链再塞一个 DMG 装的 MySQLPATH 环境变量、库文件的依赖关系很容易变得混乱。更关键的是DMG 安装包对 macOS 新版本的适配往往滞后尤其在 Apple Silicon 的机器上你下载到的 x86_64 版本要靠 Rosetta 转译性能损耗倒是其次启动时偶发的异常行为才是最头疼的。Docker 方案跑一个 mysql:5.7 容器是干净、隔离性也好特别适合只是临时要一个 5.7 环境跑测试的场景。但如果你本地开发需要频繁访问数据库、调试慢查询、看数据目录或者你的项目依赖宿主机上的某些 client 工具直接连数据库容器的网络和文件映射就多了一层心智负担。而且 Docker 本身在 Mac 上的资源占用不小开个 Docker Desktop 再跑数据库风扇转得比写代码还快。另外用 Docker 跑的 MySQL 在数据持久化和备份习惯上跟传统方式差别挺大很多旧项目的人不习惯。Homebrew 的优势一方面它对版本的管理非常清晰brew install mysql5.7装完就是 5.7brew install mysql装完就是 8.0两者可以共存切换版本也方便。另一方面brew 会帮你处理好依赖关系和 PATH 链接和系统里其他通过 brew 装的软件能做到风格统一。你后续想升级、降级、卸载一条命令解决完全可控。所以我的结论很直接如果你是在 Mac 上做日常开发Homebrew 是首选。接下来所有步骤都基于 Homebrew 展开。2. 安装前的环境检查避免装到一半翻车很多人装 MySQL 失败其实问题不是出在 MySQL 本身而是安装前没把环境理清楚。在敲安装命令之前我建议你先花两分钟确认三件事。第一你 Mac 的芯片架构。在“关于本机”里能看到是 Apple M 系列还是 Intel 芯片。这个影响 brew 给你拉取哪个架构的包也影响后续某些原生工具的编译。终端里跑uname -m输出arm64就是 Apple Silicon输出x86_64就是 Intel。虽然现代 Homebrew 已经能自动处理架构适配但了解这一点对排查问题有好处。第二Homebrew 本身装好没有版本是多少。终端执行brew --version如果提示命令不存在你需要先装 Homebrew。装 Homebrew 是个一次性动作但网络不好的时候会卡很久。如果已经装过顺手跑一下brew doctor看看有没有系统级的配置问题。brew doctor 输出的 warning 不一定每条都要处理但涉及 “unbrewed dylibs” 或 “broken symlinks” 的提示建议先解决否则后面安装其他包时可能踩边界问题。第三确认系统里是否已经存在 MySQL。包括三种残留之前用 brew 装过的 mysql 或 mysql5.7、用 DMG 装过的 MySQL、以及没走包管理器直接解压 tarball 的 MySQL。检查命令which mysql brew list --formula | grep mysql ls /usr/local/mysql 2/dev/null; ls /opt/homebrew/opt/mysql* 2/dev/null如果有旧 MySQL后续的端口冲突、数据目录权限问题基本都源于此。具体的清理方式我在第 3 章会讲。第三件容易被忽略的事是端口占用检查。MySQL 默认监听 3306 端口。如果你本机已经跑着其他数据库或者之前某个服务占用了 3306那安装后无论如何都启动不了。先看看lsof -i :3306这条命令如果没有任何输出说明端口是空闲的。如果有输出会看到占用端口的进程名和 PID你需要根据实际情况决定是停掉旧进程还是换端口。准备工作做到这里就够了不需要过度折腾系统环境。下面进入正题。3. 完整安装流程从零开始装好 MySQL 5.73.1 安装 Homebrew 与 mysql5.7如果你还没有 Homebrew先装它。在终端执行/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)这个脚本会自动安装 Command Line Tools过程比较久耐心等。装完根据终端提示把 brew 加入 PATH。接下来安装 MySQL 5.7brew install mysql5.7这个命令会拉取预编译的 bottle正常情况下几分钟内完成。注意点是如果你用的是 Apple Siliconbrew 会把包装在/opt/homebrew/opt/下Intel 的话在/usr/local/opt/。这个路径差异在后面写配置、设置 PATH 时经常用到记一下。安装完成后MySQL 5.7 默认是 keg-only 的。意思是它不会被自动链接到系统 PATH 里。原因很简单系统里可能同时有 mysql 8.0如果把 5.7 的命令也链接过去mysql命令到底指向哪个版本就会产生歧义。所以官方干脆不做自动链接把选择权留给你。这时候你需要手动把 mysql5.7 加到 PATH 里。在~/.zshrc里添加export PATH/opt/homebrew/opt/mysql5.7/bin:$PATH如果你在 Apple Silicon 上就是上面的路径如果是 Intel Mac改成/usr/local/opt/mysql5.7/bin。改完执行source ~/.zshrc让配置生效。验证一下mysql --version如果输出mysql Ver 14.14 Distrib 5.7.x for macos...之类的版本信息就说明 PATH 配置成功。我看到终端里出现“5.7”字样的时候就知道这个坑已经跨过去一半了。注意有些教程会让你直接执行brew link mysql5.7 --force。我建议不要这么做因为--force会覆盖系统里潜在的其他 mysql 链接可能导致不可预期的行为。用 PATH 这种方式更温和、可控。3.2 初始化数据目录与启动服务安装只是把文件放到硬盘上真正让 MySQL 跑起来还需要初始化数据目录。brew 安装的 mysql5.7 在首次启动时会自动初始化 datadir但为了能控制初始化参数我推荐手动执行一次初始化mysqld --initialize-insecure --user$(whoami) --datadir/opt/homebrew/var/mysql解释一下这里几个参数--initialize-insecure表示初始化时创建一个无密码的 root 用户方便本地开发。如果是生产环境应该用--initialize它会生成一个随机密码并打印在日志里。--user$(whoami)指定数据文件的属主。macOS 下开发机不建议用 root 跑 MySQL用当前用户更安全也避免文件权限问题。注意MySQL 5.7 对数据目录的权限非常敏感如果 datadir 的所有者是 root启动时大概率报错。--datadir指定数据目录。如果你不确定 brew 的 datadir 默认位置可以先用brew --prefix mysql5.7查看安装路径再确认 var/mysql 目录是否存在。没有的话手动mkdir一下。初始化完成后目录里会出现mysql、performance_schema、sys等系统库文件。这一步成功说明 bin 目录下的二进制文件能正常运行。启动方式有两种。第一种是临时启动前台运行适合快速验证mysqld_safe --datadir/opt/homebrew/var/mysql 第二种是后台服务方式用 brew servicesbrew services start mysql5.7brew services会把 MySQL 注册成 launchd 服务并设置开机自启。如果你只是临时用用不想开机自启可以不执行这条而是每次手动启动。我个人建议开发机用brew services start省心但如果你担心开机自启占用资源用brew services run mysql5.7只启动一次不设置开机自启。启动后确认进程正常mysqladmin -u root ping看到mysqld is alive就说明服务起来了。到这一步MySQL 5.7 已经能正常连接了只不过还是无密码状态需要做安全加固。3.3 执行安全配置脚本设置密码与调整访问策略MySQL 5.7 自带了mysql_secure_installation这个安全脚本帮你完成设置 root 密码、删除匿名用户、禁止 root 远程登录等操作。建议装完必跑mysql_secure_installation执行后会有一系列交互问答。注意几个关键选择设置 root 密码输入一个强密码至少 8 位包含大小写字母和数字。如果你后续要从应用代码里连数据库密码里的特殊字符要注意转义问题建议先不要用$、这种 shell 或配置文件里容易出问题的字符免得排查半天。删除匿名用户选 Y。禁止 root 远程登录选 Y。本地开发一般直接rootlocalhost连就够了。删除 test 数据库并访问选 Y。重新加载权限表选 Y。跑完之后root 用户就是带密码状态了。验证一下mysql -u root -p Enter password:输入密码后能进入mysql交互界面说明一切正常。到这里一个基础的 MySQL 5.7 已经可以用了。不过我想多说一句这个安全脚本的本意是面向服务器的本地开发机上跑一遍也没毛病但当你日后需要临时用 root 做某些操作密码就是一道关卡。所以务必把密码记在你自己的密码管理工具里别再出现拿着密码却忘了存在哪的尴尬局面。3.4 设置字符集避免中文乱码的根源性问题MySQL 5.7 默认的字符集是latin1这对中文用户来说是个大坑。如果表结构或者连接串里没有显式指定字符集写入的中文很可能在存储和读取时变成乱码。更隐蔽的是有些表的排序规则不一致会导致查询结果和预期不符。最稳妥的做法是从源头统一字符集。修改配置文件my.cnf把服务端默认字符集设为utf8mb4。brew 安装的 mysql5.7配置文件路径一般在/opt/homebrew/etc/my.cnf。如果你找不到这个文件可以通过mysqld --verbose --help | grep my.cnf查看它读取配置文件的顺序和路径。打开 my.cnf在[mysqld]段下添加[mysqld] character-set-server utf8mb4 collation-server utf8mb4_general_ci skip-character-set-client-handshake逐行解释character-set-server指定服务端字符集。utf8mb4是真正的“完整 UTF-8”能存 emoji 和其他四字节字符。不要用utf8那只是utf8mb3存 emoji 会直接报错或丢字符。collation-server指定排序规则。utf8mb4_general_ci是通用规则大小写不敏感适合大多数场景。如果你的业务涉及多语言排序可以考虑utf8mb4_unicode_ci排序更准确但性能略逊。开发环境无所谓用 general_ci 即可。skip-character-set-client-handshake是让服务端忽略客户端的字符集声明统一按服务端配置来。这一项能避免不同客户端因字符集不一致产生乱码。不过加了它之后连接串里再指定字符集就不起作用了所以是否加看你的团队约定。我开发现场一般会加。另外在[client]段下也可以加一句[client] default-character-set utf8mb4这样用命令行客户端连接时字符集也是 utf8mb4。改完重启 MySQLbrew services restart mysql5.7验证当前字符集SHOW VARIABLES LIKE character_set%; SHOW VARIABLES LIKE collation%;看到character_set_server的值为utf8mb4就说明配置生效了。这一步提前做后面建库建表就省心很多。3.5 创建业务库和业务账号安全脚本跑完之后root 密码已经设好但实际开发中你不太可能一直用 root 连库。更规范的做法是给项目单独创建一个数据库和一个账号权限按需分配日后即便泄露也不会把整个实例搭进去。进入 MySQLmysql -u root -p创建数据库CREATE DATABASE IF NOT EXISTS demo_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;创建用户并授权CREATE USER demo_userlocalhost IDENTIFIED BY YourStrongPass123; GRANT SELECT, INSERT, UPDATE, DELETE ON demo_db.* TO demo_userlocalhost; FLUSH PRIVILEGES;这里我给的是只增删改查的权限没有给 DDL建表、删表权限。开发环境有的人图省事会直接GRANT ALL ON demo_db.*我没拦你的意思但如果是给 CI 或测试脚本用的账号还是收敛一点好。先给最小权限不够了再补这个习惯在团队协作里非常加分。到这里安装、初始化、安全配置、字符集、账号就全部齐了MySQL 5.7 在 macOS 上可以正常服役了。如果你只是要一个能用的数据库看到这里就可以收工了。但如果你想把本地环境弄得更顺手或者之后还打算做性能调优、排障下面的内容更值得继续看。4. 深入配置连接数、慢查询与日志4.1 连接数与内存配置MySQL 5.7 默认配置对开发机够用但如果你要在本地跑一些压力测试或者同时打开多个应用连接默认的max_connections可能会不够。默认值是 151对一个本地开发库来说一般也够了但你要是开着多个服务每个服务建连接池很容易把这个数打满。在[mysqld]段下加max_connections 512内存方面5.7 的默认innodb_buffer_pool_size是 128M这个值偏小但对本地开发来说其实反而友好不占内存。如果你的 Mac 内存 16G 以上舍得给 MySQL 分一点可以调成 512Minnodb_buffer_pool_size 512M注意buffer pool 在 5.7 里必须是 1M 的整数倍否则启动会报错。这个细节文档里不一定写清楚但实测踩过。4.2 开启慢查询日志本地开发环境下慢查询日志可能比生产环境更能帮你发现问题。因为生产环境有监控平台本地没有写了一个低效查询走了全表扫描可能表数据量小感觉不到但上线后表一变大就出大事。提前把慢查询打开心里有底。在 my.cnf 中添加slow_query_log 1 slow_query_log_file /opt/homebrew/var/mysql/slow.log long_query_time 1long_query_time 1表示超过 1 秒的都记下来。开发环境这个阈值可以定得严一点生产环境一般建议 2 到 3 秒否则日志量会很大。改完重启随便跑几条查询再用tail -f /opt/homebrew/var/mysql/slow.log看一眼有没有记录。4.3 二进制日志与数据安全MySQL 5.7 默认没开log_bin但如果你希望本地环境也模拟生产环境的 binlog 行为或者你之后要做基于 binlog 的数据同步那现在就打开它。server-id 1 log_bin /opt/homebrew/var/mysql/binlog expire_logs_days 7server-id必填否则启动报错。expire_logs_days控制 binlog 保留天数本地开发设个 7 天就够免得磁盘被撑爆。开了 binlog 之后SHOW MASTER STATUS;就能看到当前的 binlog 文件和位置这在你之后搭建从库或做数据恢复时是很有用的信息。开发环境要不要开 binlog取决于你团队对本地环境的要求如果没有人要求开不开都行但它确实是好习惯。4.4 TIME_ZONE 设置数据库时区是个容易被忽略的配置。默认情况下 MySQL 用系统时区。如果你的 Mac 时区设置没问题MySQL 一般也会对。但有些云主机的系统时区是 UTC生产库的time_zone就会和本地不一样导致写入的时间戳出现偏差。为了避免后续开发时发现时间对不上最好在开发环境也把时区显式设成你所在时区。在 my.cnf 中加入default-time-zone 08:00改成你所在时区的偏移量即可。重启后SELECT NOW();应该和你的本地时间一致。5. 踩坑实录与排查思路我这边安装和之后几天的使用里遇到了几个非常有代表性的问题。挑几个写出来每个都附带排查思路。这些问题网上都有零散讨论但真正遇到的时候很多人还是会卡很久。5.1 服务启动失败数据目录权限错误首次遇到的比较典型的问题是mysqld启动时提示Permission denied或Cant create/write to file。原因绝大多数是数据目录的属主不对。我排查这类问题的固定路径是ls -ld /opt/homebrew/var/mysql正常情况下属主应该是你当前的用户名。如果显示的是 root直接改回来sudo chown -R $(whoami):admin /opt/homebrew/var/mysql注意如果数据目录已经初始化过而且里面有数据文件改属主之前最好确认没有其他进程在用这个目录否则可能造成文件占用、权限错乱。另一个隐蔽的问题是用mysqld_safe启动时它会把进程切换成mysql用户运行如果mysql用户对 datadir 没有写权限一样启动失败。所以如果你手动mysqld_safe --datadir...启动要确保你指定的 datadir 的正确属主是 mysql 用户或当前用户。总之一个原则datadir 的属主必须覆盖 mysqld 实际运行时使用的系统用户。5.2 端口被占用3306 起不来的另一个常见原因如果你运行brew services start mysql5.7之后服务显示起来了但mysql -u root -p连接时提示Cant connect to local MySQL server through socket多半是 mysqld 实际上没起来。这时候看日志tail -100 /opt/homebrew/var/mysql/*.err日志里如果有Bind on TCP/IP port: Address already in use那 3306 端口已经被占了。先找出占用进程lsof -i :3306拿到 PID 后确认一下这个进程是不是另一个 MySQL 实例。如果是你自己之前手动启动了另一个 mysqld直接kill那个 PID。如果是别的不认识的服务那 3306 冲突了考虑换端口。换个端口有两种改法。一是在 my.cnf 里改port 3307二是启动时用--port3307参数临时指定。开发机自用的话改 my.cnf 会比较省事但所有连接串都要跟着改。我一般在本地开发机上会把数据库端口固定用一个非常见端口比如 3307而不是默认的 3306这样能避开很多莫名其妙被占用的冲突。坏处是你团队里其他人如果习惯默认 3306看到你的连接串会愣一下。所以要是团队有统一规范就别自己秀特殊。5.3 密码策略导致设置弱密码失败MySQL 5.7 默认安装了 validate_password 插件对密码强度有要求。如果你在安全配置脚本里想设一个简单密码比如123456会直接报错提示不符合密码策略。如果你明确知道这是本地开发环境不在乎所谓的密码强度可以用下面的命令弱化策略SET GLOBAL validate_password_policy LOW; SET GLOBAL validate_password_length 6;LOW策略只校验密码长度不要求大小写字母混合。validate_password_length可以设小一点。注意这两个设置是运行时生效但重启后会失效。想在重启后仍然保持低策略需要写进 my.cnf[mysqld] validate_password_policy LOW validate_password_length 6这个插件的存在有时候会很烦但它是 5.7 的默认安全组件。如果你本地开发完全不需要它也可以在 my.cnf 里加一行plugin-load-add validate_password.so的反向操作不对正确做法是启动时加上--skip-validate-password参数跳过。不过版本不同参数名可能不同5.7 里直接配置validate_password_policyLOW最简单。5.4 升级 macOS 之后 MySQL 无法启动如果你系统从旧版 macOS 升级上来或者刚做完一次大版本更新MySQL 服务突然起不来了日志里报错和 SSL 库相关比如Failed to initialize SSL context那大概率是系统里 OpenSSL 库的版本或路径变了MySQL 5.7 的动态链接找不到了。排查方式otool -L /opt/homebrew/opt/mysql5.7/bin/mysqld | grep ssl看引用的库是否存在。如果引用的路径不存在最简单的修复方式是重装一次 mysql5.7brew reinstall mysql5.7它会重新链接当前系统的依赖库。我不想过度夸大这个操作的副作用但重装会保留 datadir不会丢数据只是重新编译/链接二进制。放心执行。5.5 字符集导致的查询结果乱码这是老生常谈但每次都会有人踩。现象是通过命令行客户端插入中文后用程序客户端读出来乱码或者反过来。排查思路就一条沿着字符集的链路逐层检查。SHOW VARIABLES LIKE character_set%;重点关注几个变量character_set_client、character_set_connection、character_set_results。如果都是 utf8mb4一般不会乱码。问题大多出在连接的建立阶段。比如你用 JDBC 连接串没加characterEncodingutf8或者某个 ORM 框架的 driver 在连接初始化时发送了错误的 SET NAMES 语句。如果没加skip-character-set-client-handshakeMySQL 会按客户端发来的字符集声明做转换这本身没问题问题是客户端声明的不对。所以最省事的还是服务端统一强制 utf8mb4不让客户端左右。这也是我前面推荐skip-character-set-client-handshake的真实原因。5.6 安装时 brew 提示 mysql5.7 未找到如果你执行brew install mysql5.7时提示 “No formulae found for mysql5.7”可能性有两个一是你本机 brew 的 formulae 索引没更新先brew update再装二是某些镜像源没有同步 mysql5.7 这个版本。如果是公司内部网络代理或镜像源建议先切回官方源装完再切回来。某些过时的教程会推荐brew install homebrew/versions/mysql5.7但这个 tap 已经废弃了不建议用。6. 卸载与清理本地环境换版本的正确姿势如果你装完之后发现 5.7 其实不是你要的版本或者想彻底清干净换 8.0完整的卸载流程比安装更值得讲清楚。因为卸载不干净再装别的版本时各种残留会让问题更加隐蔽。第一步停服务brew services stop mysql5.7第二步卸载 formulabrew uninstall mysql5.7第三步清理残留文件。brew uninstall 并不会删除 datadir 和配置文件这两个通常是最占空间也最容易藏问题的地方rm -rf /opt/homebrew/var/mysql rm -f /opt/homebrew/etc/my.cnf如果你之前用 DMG 安装过还要检查/usr/local/mysql或/Library/LaunchDaemons/com.oracle.oss.mysql.*这类目录和 plist 文件有的话一并删除。然后检查 PATH 里有没有残留的 mysql 路径which mysql如果mysql命令还指向某个不存在的路径检查~/.zshrc或~/.bash_profile把之前加的 export 行删掉。至此系统里跟 MySQL 5.7 相关的东西就都清干净了。之后想装 8.0 就直接brew install mysql不会再被旧残留干扰。7. 多种安装方式对照要不要考虑 Docker 和 DMG我知道写到这里你可能会想是不是还有更好的方式我把 Docker 和 DMG 两种方式的优缺点再补完供你做最后决策。Docker 方式最明显的优势是干净。MySQL 跑在容器里几乎所有依赖都和宿主机隔离。你不需要关心 brew 的 keg-only 问题不需要处理 datadir 权限卸载就是一条docker rm -f的事。如果你经常要切换 MySQL 版本做兼容性测试Docker 开两个容器跑 5.7 和 8.0 互不干扰确实省心。但 Docker 的代价是资源占用要高出一截文件 IO 性能比原生进程差一些本地开发涉及大数据量导入导出的时候体感明显。另外容器里的 MySQL 默认不开放远程连接需要额外设置端口映射和认证插件这些步骤对新手来说比直接装原生版本要难理解。所以我的建议是如果你只是想要一个临时的数据库做验证选 Docker如果你希望本地环境尽可能接近传统服务器部署方式选 Homebrew。DMG 方式呢除非你的机器完全不具备 Homebrew 条件比如某些受管控的办公电脑不能装 brew否则我确实不推荐。DMG 的安装路径不规则卸载又需要手动删一堆文件而且很容易和新版本的其他 MySQL 组件起冲突。它的唯一好处是安装界面傻瓜化但后续的维护成本偏高。8. 写在最后的几个经验折腾完这一整套有几条经验我想单独拎出来说。第一能用官方工具链就尽量别自己折腾源码编译。MySQL 5.7 从源码编译在 macOS 上的坑非常多编译器版本、openssl 路径、boost 版本任何一个不匹配都可能让你卡上一整天。Homebrew 的预编译包已经帮你把大部分兼容性问题处理掉了没有特殊需求就别去自虐。第二配置文件的注释要写清楚。本地环境的 my.cnf 很容易被遗忘几个月后你再看已经忘了某一行配置当时是为解决什么问题加的了。我习惯在改配置的时候顺手写一行注释标注日期和原因比如# 2024-11-05 避免中文乱码统一 utf8mb4。这个习惯帮我在之后排查问题时省了很多时间。第三密码管理要趁早。本地数据库的 root 密码设好之后最好立刻记到密码管理器里。不要觉得“本地环境而已密码随意”等到你的项目配置、CI 脚本、同事连接串全部依赖这个密码之后再想改就是牵一发动全身。第四安装完成后做个快照。如果你用的是虚拟机或云桌面装完且验证没问题后打个快照后续折腾坏了可以秒级恢复。物理机的话至少把 my.cnf 和初始化命令存个档这样重建环境时照着执行一遍就行。MySQL 5.7 确实已经不算新了但它在存量项目里的地位短期内不会消失。掌握如何在 macOS 上把它装好、配好、用好对一个开发者的日常工作是实打实的帮助。希望这篇文章能让你少踩几个我已经踩过的坑。
阅读完成 · 觉得有帮助？
