macOS 上用 brew 安装 MySQL 后，服务没自动启动怎么办
brew install mysql 默认不会启用开机自启，
mysql命令能用，但
mysql -u root连不上，大概率是
mysqld进程根本没在跑。别急着重装，先确认服务状态。 检查是否已安装：运行
brew services list | grep mysql，如果显示
none或空白，说明服务未注册 确认安装路径：brew 安装的 MySQL 通常在
/opt/homebrew/opt/mysql（Apple Silicon）或
/usr/local/opt/mysql（Intel），配置文件默认是
my.cnf，但 brew 不会自动生成，得自己处理 不要手动执行
mysqld &—— 这样启的进程没有日志、不响应 brew 管理指令，且下次重启就丢了
用 brew services 启动并设置开机自启
这是最稳的方式，全程由 brew 管理生命周期，避免权限、路径、用户上下文错乱。
首次启动（不自启）：brew services start mysql设为开机自启：
brew services restart mysql（restart 会自动启用 launchd plist 并 reload） 验证是否跑起来了：
brew services list应显示
mysql状态为
started；再执行
ps aux | grep mysqld，能看到带
--datadir和
--pid-file参数的进程 如果报
Permission denied，大概率是 /opt/homebrew/var/mysql（或 /usr/local/var/mysql）目录属主不对，运行
sudo chown -R $(whoami) /opt/homebrew/var/mysql（路径按你实际安装位置调整）
连接失败时，重点查这三个地方
即使
mysqld在跑，
mysql -u root仍可能报
Access denied或
Can't connect to local MySQL server，原因往往不在网络，而在本地认证逻辑。 默认 root 密码为空？不一定。Mojave 及之后版本，brew 安装后首次运行会生成临时密码，藏在错误日志里：
tail -n 20 /opt/homebrew/var/mysql/*.err，找含
A temporary password的行 认证插件可能是
caching_sha2_password，而老客户端不支持。临时解决：用
mysql -u root -p登录后执行
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';socket 路径不对。brew 默认 socket 是
/opt/homebrew/var/run/mysql.sock，但客户端可能去
/tmp/mysql.sock找。加
--socket=/opt/homebrew/var/run/mysql.sock显式指定，或软链：
ln -sf /opt/homebrew/var/run/mysql.sock /tmp/mysql.sock
不想用 brew services？手动启服务要绕开两个坑
有些场景（比如调试启动参数、换 datadir）必须手动启，但直接跑
mysqld很容易掉进权限和路径陷阱。 别用
sudo mysqld—— 这会让数据目录属主变成 root，后续 brew services 就无法接管 务必指定用户：
mysqld --user=$(whoami) --datadir=/opt/homebrew/var/mysql --socket=/opt/homebrew/var/run/mysql.sock第一次初始化数据目录要加
--initialize-insecure（空密码）或
--initialize（生成临时密码），但 brew 已帮你干过这事，重复执行会报错“Data directory already exists” 手动启的服务不会写 pid 文件到 brew 预期位置，
brew services stop mysql会失效，得自己
kill进程 brew 把服务管理做得挺干净，但它的默认行为和传统 Linux 发行版差异不小。最关键的不是“怎么启”，而是“谁在管它”——一旦混用 brew services 和手启，
mysqld进程归属、socket 位置、日志路径全会错位，排查起来比重装还费时间。
