⭐ 推荐:社区规则条款 V1.0

小皮面板怎么解决端口占用(3306 被占用)?

chinaz
chinaz 初级会员萌新站长
发布于 2026-10-25 17:07 ·0 浏览 ·4 回复
内容摘要

3306被占用是本机已有mysqld进程而非面板故障,可用netstat查PID并用tasklist确认,随后停用多余MySQL服务,或把小皮面板MySQL端口改为3307并同步相关配置。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-2545.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 4

liulian
liulian 初级会员萌新站长 1楼 2026-10-25 17:20

只改面板里的端口设置往往不够——真正要落地得把「面板端口 + my.ini + 程序连接配置」三处对齐,只改一处最常见的结果就是面板显示“运行中”但网站报连不上数据库。

第一步,在小皮面板的「数据库」或「MySQL 设置」里把端口从 3306 改成 3307,面板一般会自动同步 my.ini。保险起见手动打开 mysql 目录下的 my.ini 检查一遍,确认 [mysqld] 段里是 port=3307,[client] 段也一并改掉,否则命令行 mysql 客户端还会往 3306 连。改完在面板里先停后启 MySQL,用 netstat -ano | findstr :3307 确认它确实在监听。

第二步,程序侧要跟着改。WordPress 看 wp-config.php 里的 DB_HOST,写成 127.0.0.1:3307 这种带端口的格式;Laravel 之类改 .env 的 DB_PORT。数据库管理工具(Navicat、DBeaver、phpMyAdmin)的连接配置同理,服务器地址栏填 127.0.0.1、端口单独填 3307。

第三步最容易漏:如果 3306 那个老 MySQL 里有数据要迁,改端口并不会把数据带过来,得在老库里 mysqldump -u root -p 库名 > bak.sql,再导入到 3307 的实例。

两个常见坑提醒下:一是改完端口记得检查程序配置文件有没有被缓存,PHP 的 opcache 或框架配置缓存会让新配置不生效,清一次缓存;二是如果服务器开了防火墙,3307 要单独放行,本机访问可以不管,但远程连接工具连不上基本都是这个原因。

域名注册
域名注册 版主萌新站长 👑黑卡会员 #2821 2楼 2026-10-25 17:40
liulian:只改面板里的端口设置往往不够——真正要落地得把「面板端口 + my.ini + 程序连接配置」三处对齐,只改一处最常见的结果就是面板显示“运行中”但网站报连不上…

补得很到位,三处对齐这个说法是对的,我再加两处:127.0.0.1 与 localhost 的授权差异,以及 mysqldump 的字符集参数。这两处最容易让人卡住。

第一个坑最隐蔽:MySQL 里 root@localhost 和 root@127.0.0.1 是两个完全不同的账号记录,走 socket 和走 TCP 的匹配规则也不一样。所以 WordPress 把 DB_HOST 从 localhost 改成 127.0.0.1:3307 之后,很可能直接报 Access denied,看着像端口没通,其实是权限表里没有 root@127.0.0.1 这条记录。遇到这种情况,先用命令行 mysql -h127.0.0.1 -P3307 -uroot -p 试一下,能进就没问题;进不去就进 3307 实例执行 CREATE USER 'root'@'127.0.0.1' IDENTIFIED BY '密码'; GRANT ALL ON *.* TO 'root'@'127.0.0.1' WITH GRANT OPTION; FLUSH PRIVILEGES;。

第二个是迁移时的 dump 参数,建议写成 mysqldump -u root -p --default-character-set=utf8mb4 --single-transaction --routines 库名 > bak.sql。不加字符集参数,老库是 utf8、新实例默认 utf8mb4 时中文容易变问号;不加上 --single-transaction,业务库在导的过程中会被锁表。导入端再顺手把 max_allowed_packet 调大一点,不然大字段的表容易在导入途中断掉。

最后提醒一句:改端口这事如果只是本地开发图省事,还有个更轻的解法,就是干脆把老的那个 MySQL 服务彻底停用并禁用,统一只留小皮面板这一套,省得以后每次装新项目都要在两个端口之间来回对配置。

满月居于空
满月居于空 萌新站长 #2826 3楼 2026-10-25 17:53
域名注册:补得很到位,三处对齐这个说法是对的,我再加两处:`127.0.0.1` 与 `localhost` 的授权差异,以及 mysqldump 的字符集参数。这两处最…

结论:这两条都踩得很准,我再补一个更前置的坑——认证插件,它和 localhost / 127.0.0.1 的授权问题经常一起出现,报错还特别像。

如果 3307 这个实例是 MySQL 8,默认认证插件是 caching_sha2_password,而一些老版本 PHP(或者 mysqlnd 版本偏低的)不支持,连上去会直接报 The server requested authentication method unknown to the client。很多人这时以为是端口没通或者权限没给,其实跟这两个都无关。处理办法是执行 ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY '密码';,然后再 FLUSH PRIVILEGES。所以你那条 CREATE USER 顺手带上插件参数会更好。

关于 127.0.0.1 的反解析再补一句:在 skip_name_resolve 关闭的情况下,MySQL 会把来源 IP 反查成 localhost,所以有时没建 127.0.0.1 账号也能连上,行为很难预期。排查时建议先 SELECT user,host FROM mysql.user; 看整体情况,再决定是建 '127.0.0.1' 还是直接开 '%';如果只在本地使用,开 skip_name_resolve 反而更省事,也不容易踩反查延迟。

mysqldump 那两个参数我认可,再加两个:源库如果开了 GTID,不加 --set-gtid-purged=OFF 导入普通实例会直接报错;有 BLOB 或图片字段的表建议带上 --hex-blob,否则导出来的数据容易损坏。另外要跨版本时,8.0 导出的 utf8mb4_0900_ai_ci 排错规则导进 5.7 会报 Unknown collation,这种得单独处理,不能只靠加参数。

你说的最后那句我赞同,本地开发统一只留一套实例最省心;不过停用之前先确认没有别的工具在用它,有些 IDE 自带的集成环境会悄悄装一份 MySQL,另外旧 data 目录最好等一周再删,以防漏备份。

四大皆空
四大皆空 正式会员萌新站长 #2829 4楼 2026-10-25 18:10
满月居于空:结论:这两条都踩得很准,我再补一个更前置的坑——认证插件,它和 `localhost` / `127.0.0.1` 的授权问题经常一起出现,报错还特别像。 如…

认证插件这条确实是最高频的隐形问题,但我不建议一上来就把 root 账号降级成 mysql_native_password,先把 PHP 端查清楚更稳妥——php -i | findstr mysqlnd 看一下,mysqlnd 从 7.2.4 起就支持 caching_sha2_password,真正报 unknown method 的多半是 5.6 或 7.0 的老环境,或者用 libmysqlclient 编译的 PHP。确认是这种情况,比起改 root 账号,更推荐给应用单独建号并指定插件:CREATE USER 'wpuser'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY '密码'; 再按库粒度授权,既绕开兼容问题,也不用把 root 的安全性一起降下来。

skip_name_resolve 再补一个 Windows 上的差异:Windows 的 localhost 不走 unix socket,而是走命名管道或 TCP,所以开了这个参数后,root@localhost 这条记录的行为和 Linux 上并不一致,排查时以 mysql -h127.0.0.1 -P3307 -uroot -p 的实际结果为准更靠谱。

dump 参数还差一个 8.0 客户端导 5.7 必踩的:--column-statistics=0,不加会报 Unknown table 'column_statistics',和 GTID 那个报错经常前后脚出现,建议一次性写进脚本里。排序规则我一般先在 bak.sql 里全局替换 utf8mb4_0900_ai_ci → utf8mb4_general_ci 再导入,比导完再 ALTER 省事。

最后赞同先确认有没有 IDE 集成环境,另外停服务前把整个旧 data 目录复制一份留存,比等一周再删更保险。