MySQL从零到稳定：安装配置、表设计、存储过程与故障排障全攻略-代码聚汇网

MySQL从零到稳定：安装配置、表设计、存储过程与故障排障全攻略

南瓜丶奇迹师·2026-09-04·阅读 77 GEO检测（免费）

MySQL安装教程MySQL配置存储过程

|难度：普通|阅读约 29 分钟

那段时间一个很常见的场景，就是我帮同事收拾“烂摊子”，MySQL 刚装好，localhost 都连不进去；或者存储过程写完一执行，报错信息根本不指向你写错了哪一行；又或者 Navicat 昨天连得好好，今天突然告诉我连接失败。正是这些琐碎但在热搜中反复出现的 MySQL 细节，让我决定把自己“创建 MySQL”的完整积累整理出来。这篇文章会覆盖从 MySQL 安装配置、环境变量、端口号设置，到学生成绩库表设计、存储过程与触发器中分隔符的处理、Explain 执行计划、锁表定位、行转列写法、以及 Error 2002 和忘记密码的排查链路。它不是单一安装教程，而是一条把 MySQL 从零建起来、用起来、稳住的经验地图。如果你正准备搭一套 MySQL，或者已经建好但卡在某个具体问题上，往下看你大概率能找到对应的解。

1. 版本选型和环境安装：MySQL实例能不能活，第一步就很关键

1.1 别盲目追新：从 5.7 升 8.0 前先搞清楚默认认证插件

很多人在搜“mysql 安装教程”时，第一件事就是把官网最新的版本下载下来。我这里必须先说一个反直觉的经验：MySQL 版本的新旧，直接影响你后续的工具兼容性，尤其是 8.0 默认的 caching_sha2_password 认证插件会让不少老版本客户端直接翻车。

我第一次在生产环境从 5.7 升到 8.0 时，最典型的反应是：应用服务没动，数据库连不上了。原因就是 8.0 引入了新的默认认证插件，而老项目里的 JDBC 驱动或 Navicat 版本还是旧时代的产物，不认识新插件。如果你搜过“navicat 连接 mysql”，会发现大量帖子都指向这个坑。

所以正确的版本选择逻辑应该是这样：

如果你的场景是全新项目、没有历史包袱，直接用 8.0 及以上，因为后续维护和官方支持周期更长。
如果你的项目里有大量老驱动、老运维脚本、老版图形客户端，先确认能否升级客户端，否则可以继续留在 5.7 的长期支持版本上。
生产环境不要下载 RC 版或 Development 版，老老实实选 GA 稳定版。

当你已经安装好 8.0 又必须兼容老客户端时，不用急着卸载，可以创建用户时显式指定 mysql_native_password：

sql复制CREATE USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'YourPassword';
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'YourPassword';

1.2 Linux、Windows 和 Mac 安装的三个常见检查点

热搜里有“linux 安装 mysql 详细步骤”“mysql 安装教程 macbook”“mysql 安装到 d 盘教程”，说明很多人卡在不同系统的相同点上：安装命令好找，安装完之后的后续配置反而容易忘。

在 Linux 上，我强烈建议优先用发行版自己的包管理器安装，而不是去官网下载二进制包手动解压。比如 CentOS/RHEL 系列：

bash复制sudo yum install -y mysql-server
sudo systemctl start mysqld
sudo systemctl enable mysqld

装完以后第一件事不是急着登录，而是去日志里找初始密码。通常在：

bash复制sudo grep 'temporary password' /var/log/mysqld.log

这一步错过了，后面就变成“mysql 忘记数据库密码怎么办”。千万别问我是怎么知道的。

Windows 上安装到一个非 C 盘目录是很多人的执念，但请注意，MySQL 安装包默认会把数据目录写到 C:\ProgramData\MySQL\MySQL Server 8.0\Data。如果你用的是免安装 zip 包，关键不在于 basedir 写在哪，而在于 my.ini 里的 datadir 是否指向你期望的 D 盘目录。很多人改完 my.ini 不生效，原因就是 basedir 与 datadir 中间有空格，路径没加引号，或者初始化时用的路径不统一。

Mac 上最容易踩的坑不是安装，而是环境变量。用 mysql -u root -p 时报 command not found，多半是因为 /usr/local/mysql/bin 没有加进 PATH。如果你用的是 zsh，需要写入 ~/.zshrc，而不是 ~/.bash_profile：

bash复制export PATH=$PATH:/usr/local/mysql/bin
source ~/.zshrc

1.3 端口号、环境变量和安全基线，安装完的十分钟内必须处理

关于“mysql 端口号”，很多人只知道 3306，却不知道以下几件事：第一，MySQL 默认监听 3306/TCP，但 Linux 上还会创建一个 /tmp/mysql.sock 的本地 socket 文件；第二，客户端连接时如果指定 localhost，MySQL 会优先走 socket；第三，你用 netstat -anp | grep 3306 看到服务监听了，不代表防火墙放行了，很多远程连接失败和端口根本没通是两回事。

我一般安装完立刻检查端口监听状态和基础安全配置：

bash复制netstat -tanlp | grep 3306
mysql_secure_installation

mysql_secure_installation 会引导你移除匿名用户、禁用 root 远程登录、删除测试库。请注意，我见过不少人跳过了这一步，结果数据库里被写入勒索提示。内网环境同样有风险，别偷懒。

环境变量的问题则需要区分是“给客户端用”还是“给系统服务用”。Linux 上把 mysql 客户端路径加入 PATH 很重要，Windows 上的 mysql 命令同样需要把 bin 目录加入系统 Path 变量，否则你在命令行里敲 mysql 永远提示“不是内部或外部命令”。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 库表建模与基础 SQL：从学生成绩系统看两难取舍

2.1 学生课程成绩信息实体表：一个普通业务表的建模经验

热搜里有一组词特别能代表新人需求：“学生课程成绩信息实体表设计 mysql”。这个需求看似简单，其实能说明很多建模中的基本矛盾。

最蠢的设计是把课程名称直接当作一个字段存进成绩表，比如一张表里列出 语文成绩、数学成绩、英语成绩。这种“横表”的好处是查询直观，但这种设计的扩展性为零。如果下学期新增一门物理，你必须 ALTER TABLE 去加字段，非常痛苦。

正确的做法是拆成三张表再加一张关联表：

student：学生信息，主键 student_id
course：课程信息，主键 course_id
score：成绩表，包含 student_id、course_id、score、exam_time

sql复制CREATE TABLE student (
  student_id INT PRIMARY KEY AUTO_INCREMENT,
  student_no VARCHAR(20) NOT NULL UNIQUE,
  student_name VARCHAR(50) NOT NULL
);

CREATE TABLE course (
  course_id INT PRIMARY KEY AUTO_INCREMENT,
  course_name VARCHAR(100) NOT NULL
);

CREATE TABLE score (
  id INT PRIMARY KEY AUTO_INCREMENT,
  student_id INT NOT NULL,
  course_id INT NOT NULL,
  score DECIMAL(5,2),
  exam_time DATETIME,
  CONSTRAINT fk_score_student FOREIGN KEY (student_id) REFERENCES student(student_id),
  CONSTRAINT fk_score_course FOREIGN KEY (course_id) REFERENCES course(course_id),
  UNIQUE KEY uk_student_course_exam (student_id, course_id, exam_time)
);

为什么要给 student_id + course_id + exam_time 加唯一键？因为同一次考试，一个学生同一门课只能有一个成绩，这是业务上的天然约束。如果你不在数据库层加约束，等数据重复了再想起设置唯一约束，就会被“mysql 设置唯一已经有重复数据库”这种问题折磨。

2.2 int(11)去哪了？顺便聊聊“int+5”到底代表什么

很多自学 MySQL 的人，第一次看到网络上老教程里的 int(11) 会以为它代表整数最大位数是 11 位。这就是热搜词“mysql 中 int+5”的语境来源之一。

其实 MySQL 8.0 里 INT(11) 已经不推荐使用显示宽度了，INT 的存储范围是固定的 4 字节，有符号范围从 -2147483648 到 2147483647。你在建表时写 int(5) 不改变存储范围，只影响某些客户端展示时是否补零，而且 8.0 之后这个显示宽度已经基本废弃。真正的“限制长度”应该用 INT UNSIGNED 配合应用校验，或者改用 DECIMAL 处理小数。

至于“int+5”，我猜很多人是想验证字段值加数字时会不会溢出。实际经验是：与其纠结类型宽度，不如先确认你的业务主键增长预测。比如订单号如果超过 21 亿，用 INT 就一定会溢出，这时应该用 BIGINT。举例：

sql复制CREATE TABLE demo_table (
  counter INT UNSIGNED NOT NULL DEFAULT 0
);

如果你插入 4294967295 后执行 UPDATE demo_table SET counter = counter + 1，可能理想中的结果是一个更大数字，但这个数字已经超过了 INT UNSIGNED 范围，在严格模式下会直接报错。而如果不报错而是截断或回绕，才是真正可怕的“脏数据”。所以 MySQL 5.7 之后默认启用严格模式，我认为这反而是好事。

2.3 从 ER 图导出谈起，修改表结构为什么没有想象中简单

“mysql 的表导出 er 关系图”是很多人做项目文档时想找现成工具的需求。最实用的方法其实不复杂：

用 MySQL Workbench：连接实例后点击 Database -> Reverse Engineer，就能根据现有库生成 ER 图，并导出为 mwb 或图片。
用 mysqldump --no-data 导出结构后，在 DBeaver 里打开并生成图形化 ER 图。
如果你只想要“表间外键关系”的文字视图，可以查询 information_schema 里的表结构数据，自己整理关系。

真正让随后项目头疼的，反而是修改表结构。比如你刚上线项目后发现某张表少了一个字段，执行：

sql复制ALTER TABLE student ADD COLUMN age INT;

在小表上好像一秒钟就完成，但生产环境的大表呢？MySQL 8.0 虽然支持了部分 ALTER TABLE ... ALGORITHM=INSTANT 操作，但不是所有修改都能瞬间完成。如果你在业务高峰期直接去给一张千万行的大表增加带默认值的字段，可能造成长时间元数据锁，直到拖垮写入。我操作大表结构变更前一定会先看 SHOW PROCESSLIST，并且选择低峰期执行，或者借助 pt-online-schema-change 这样的工具。

3. 存储过程、触发器与常用函数：写的人多，讲清分隔符的少

3.1 分隔符到底是什么，为什么 CREATE PROCEDURE 前要先换掉它

在“mysql 存储过程”“mysql 中触发器中分隔符”这些热搜词背后，大量提问者的卡点不是不会写过程逻辑，而是不明白客户端是如何识别一句 SQL 结束的。

MySQL 默认用分号作为一次 SQL 输入的结束符，这没什么问题。但当你在存储过程内部写了一堆分号后，比如：

sql复制CREATE PROCEDURE p_test()
BEGIN
  DECLARE i INT DEFAULT 0;
  WHILE i < 10 DO
    SET i = i + 1;
  END WHILE;
END;

如果你的客户端仍然把分号当作完整语句结束标志，那么执行到 SET i = i + 1; 时客户端就以为自己要提交一段独立 SQL 了，后面的内容就乱了。此时你需要临时把语句结束符修改成别的，让整个过程体可以作为一个整体提交：

sql复制DELIMITER //

CREATE PROCEDURE p_test()
BEGIN
  DECLARE i INT DEFAULT 0;
  WHILE i < 10 DO
    SET i = i + 1;
  END WHILE;
END //

DELIMITER ;

注意最后一行的 DELIMITER ; 前面要有空格。这个细节在命令行客户端中尤其重要，不留空格可能把 ; 和前面的内容连在一起引发解析错误。

3.2 一个带游标的存储过程实例：为什么说小数据量用它，大数据量请谨慎

存储过程里最典型的复杂场景是“逐行遍历处理”，这就离不开游标。下面是我在实际报表任务里用过的简化示例，功能是把学生的补考记录统一调整到下一轮考试计划：

sql复制DELIMITER //

CREATE PROCEDURE sp_move_makeup_students()
BEGIN
  DECLARE v_student_id INT;
  DECLARE v_course_id INT;
  DECLARE done INT DEFAULT 0;
  DECLARE cur CURSOR FOR
    SELECT student_id, course_id FROM score WHERE score < 60 AND exam_time = '2025-01-10';
  DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

  OPEN cur;
  read_loop: LOOP
    FETCH cur INTO v_student_id, v_course_id;
    IF done = 1 THEN
      LEAVE read_loop;
    END IF;

    INSERT INTO makeup_exam(student_id, course_id, scheduled_time)
    VALUES (v_student_id, v_course_id, '2025-03-01');
  END LOOP;
  CLOSE cur;
END //

DELIMITER ;

这类过程的调试体验很差，因为 MySQL 不像普通编程语言那样有友好的断点工具。更要命的是，游标的本质是逐行取数据处理，如果结果集有几十万行，性能会明显劣于一条 INSERT ... SELECT。所以我的经验是：如果可以用一句 SQL 实现，就不要写游标；如果真需要逐行判断和调用外部逻辑，也请在测试库里先构造数据验证一遍。

3.3 常用函数、行转列和排序：现场写不出来的后遗症

热搜里“mysql 常用函数”“mysql 行转列”“mysql 排序”这几个词经常结伴出现。一旦你遇到一个复杂的报表需求，现场翻文档就慢了。

日常最高频的自用函数我先列一份：

字符串类：CONCAT、SUBSTRING、LEFT、REPLACE、TRIM
日期类：NOW、DATE_FORMAT、DATEDIFF、DATE_ADD
聚合类：COUNT、SUM、AVG、MAX、MIN
条件类：IF、CASE WHEN
窗口函数（8.0 以后）：ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)，排名、取每组前 N 条都靠它。

行转列听起来很高级，其实就是用条件聚合。一张 score 表要显示每个学生各科成绩时：

sql复制SELECT
  student_id,
  MAX(CASE WHEN course_id = 1 THEN score END) AS chinese_score,
  MAX(CASE WHEN course_id = 2 THEN score END) AS math_score,
  MAX(CASE WHEN course_id = 3 THEN score END) AS english_score
FROM score
GROUP BY student_id;

这里用 MAX 是为了配合 GROUP BY 取出每组唯一一条记录的值，不是取最大值。如果你看到这条 SQL 感觉别扭，说明你还没完全理解 CASE WHEN 与聚合的配合顺序。排序的坑则集中在中文排序上，默认 utf8mb4 按字符编码排，不是按拼音。公司里如果有按名字首字母排序的需求，我通常会在产品层解决，或者单独维护一个拼音字段。

4. 查询性能与并发问题：Explain、索引和锁等待的真实链路

4.1 Explain 出结果不等于结束，重点看 type、key、rows、Extra

“mysql explain 详解”“mysql 执行计划详解”这类词搜的人多，真正执行完能准确解释每一列含义的人少。执行 EXPLAIN SELECT ... 后，我最关心的其实只有四列：type、key、rows、Extra。

type 表示访问类型，一条良好的查询至少应该到 range 或 ref，如果出现 ALL 就代表全表扫描。大表全表扫描通常意味着查询会在数据量增长后迅速劣化。key 表示实际用到的索引，如果 possible_keys 有索引而 key 为空，说明优化器认为用索引反而更慢，或者你的查询条件存在隐式类型转换导致无法命中索引。rows 是优化器估计要扫描的行数，注意它只是估算值，但它能告诉你查询成本量级。Extra 里如果出现 Using temporary 或 Using filesort，一般说明排序或去重没有很好利用索引，数据量大时很伤。

举例：

sql复制EXPLAIN SELECT * FROM score WHERE student_id = 1001;

如果 type=ref，key=uk_student_course_exam，rows 只有几行，那这个查询基本不用优化。如果 type=ALL，rows 显示几十万行，你就要想想 student_id 上为什么没有索引。

4.2 索引失效和“自动忽略大小写”之间的隐性关联

“mysql 创建索引”本身不复杂：

sql复制CREATE INDEX idx_student_name ON student(student_name);

问题在于索引建了却没用上。以字符串字段为例，如果字段是大小写敏感的 utf8mb4_bin 排序规则，查询条件哪怕只差大小写也匹配不上；而如果是默认的 utf8mb4_0900_ai_ci，本身就是大小写不敏感。

真正挨打的场景是：你在字段上用了函数，索引直接失效。例如：

sql复制SELECT * FROM student WHERE LOWER(student_name) = 'tom';

即使你在 student_name 上建了索引，执行计划也不会采用，因为索引里存储的是原始值，不是小写后的值。解决方案可以是把字段改成大小写不敏感的排序规则，然后直接 WHERE student_name = 'Tom'；或者维护一个冗余的小写字段并给它建索引。

处理关于“mysql 自动忽略大小写”问题的时候，首先需要搞清你要的是查询时忽略大小写，还是存储时忽略重复。前者选 _ci 排序规则，后者是唯一索引加正确排序规则配合完成。很多人混淆了这两个诉求，导致结果和预期大相径庭。

4.3 锁表和锁等待：从 show processlist 开始，一步一步确认卡点

“mysql 锁表”是运维场景里的高频词。先说结论：真正意义上的“锁表”在 InnoDB 引擎里很多时候是“锁行”，表现为一个事务长时间不提交，导致其他事务在等同一行记录的锁。

我一般按下面这个链路排查：

sql复制SHOW FULL PROCESSLIST;

先看有没有大量状态为 Waiting for table metadata lock 或 Updating 的会话。如果看到 Waiting for table metadata lock，多数情况是有会话对表执行过 DDL 或者读取操作没结束。再进一步查看当前锁等待关系：

sql复制SELECT * FROM performance_schema.data_lock_waits\G
SELECT * FROM sys.innodb_lock_waits\G

确认等锁的阻塞者后，最快速的恢复手段有两个：一是联系业务方先提交或回滚那个长时间事务，二是如果事务确实已经无法正常结束，执行 KILL <thread_id> 断开会话。这里有个很容易忽略的点：你用 root 去 kill 是权限允许的，但应用连接池会自动重建会话，所以如果根源是应用代码里的事务没提交，kill 只能救急不能根治。我在生产上遇到过同样的 UPDATE 语句每天固定时长卡顿，最后定位到是应用里先查了全表又逐行更新的写法导致事务太长，改写 SQL 后锁等待彻底消失。

5. 数据导出、同步与一致性：换库比建库更容易翻车

5.1 导出一张表数据的命令，别被默认行为带偏

热搜词“mysql 导出一张表数据的命令”本质是 mysqldump 的常见用法。最简单的一条：

bash复制mysqldump -u root -p test_db student > /backup/student.sql

如果不加任何参数，这条命令会把 student 表的结构和数据一起导出，同时自动带上 DROP TABLE IF EXISTS 语句。如果你要导入到一个已经存在数据的同名表里，大概率会先把原表删掉再重建，因此线上恢复操作要格外小心。

只导出结构时不加 --no-data，只导出数据时要加 --no-create-info：

bash复制mysqldump -u root -p --no-data test_db student > student_schema.sql
mysqldump -u root -p --no-create-info test_db student > student_data.sql

还有一个高频问题：备份中文乱码。安装好 MySQL 后我建议统一确认字符集，导出的 SQL 文件默认自带 SET NAMES utf8mb4，但如果数据库连接本身字符集不对，数据在导出时就已经错了。日常环境我在 .my.cnf 或连接命令里显式加 --default-character-set=utf8mb4。如果你导出的文件要给别人导入，保持库表字段字符集一致比临时改文件再转码省心得多。

5.2 数据库同步软件：datax、Sqoop 连接问题的第一反应

热搜中有一类词很典型：“mysql/sqlserver/postgresql 数据库同步软件”“datax 同步 mysql 可配置参数”“sqoop 连接不上 mysql”。

先区分场景：如果你要做异构数据库之间的批量同步，datax 和 Sqoop 都是经典选择。Sqoop 依赖 Hadoop 生态，适合大数据量离线导入；如果只是为了轻量地在两个关系型数据库间搬数据，datax 更友好。搜“datax 同步 mysql 可配置参数”时，需要关心的核心参数通常是读取端的 splitPk、写入端的 preSql/postSql、以及 batchSize。splitPk 可以用来分片并发读取，但如果表里没有合适的数值主键，用不好会造成数据重复或负载失衡。

“sqoop 连接不上 mysql”的报错里，最高频的原因可以归结为三层：

JDBC 驱动版本不对：Sqoop 对 MySQL 8.x 需要 mysql-connector-java 8.x，很多环境下还是老驱动，连 8.0 的认证插件会失败。
数据库连接权限问题：用 sqoop list-databases --connect jdbc:mysql://ip:3306/test_db --username root --password xxx 测试，如果失败就先看 MySQL 侧用户授权是否允许 % 主机访问。
网络端口没通：Sqoop 运行的服务端不一定能访问 MySQL 的 IP，先 telnet ip 3306 验证。

5.3 设置唯一索引却发现已有重复数据怎么办

热搜里“mysql 设置唯一已经有重复数据库”的问题，需要先处理存量数据再建索引。如果有人只是想用唯一约束防止将来重复，就急匆匆执行 ALTER TABLE ... ADD UNIQUE KEY，MySQL 会直接告诉你 Duplicate entry。我习惯按以下顺序处理：

sql复制-- 先找出重复组
SELECT target_field, COUNT(*) FROM target_table GROUP BY target_field HAVING COUNT(*) > 1;

-- 根据自己的业务规则，保留每组中 id 最小的一条，删除其余重复
DELETE t1 FROM target_table t1
INNER JOIN target_table t2
WHERE t1.target_field = t2.target_field
  AND t1.id > t2.id;

删除前一定先备份。这个 SQL 在重复数据量较大时也需要注意事务大小，最好在低峰期执行。等到数据干净了，再去创建唯一索引，基本一次就能成功。

6. 连接故障排查：不是密码错，就是 socket 和认证在捣乱

6.1 Error 2002 (HY000) 的现场还原：socket 路径和监听状态

“error 2002 (hy000): can't connect to local mysql server through socket '/tmp/mysql.sock'”这串报错，我把它视为 MySQL 连接故障的入门课。它明确告诉你客户端想通过 /tmp/mysql.sock 这个 socket 文件连接本地服务，但找不到文件或权限不够。

出现这个错误的第一反应是：MySQL 服务到底有没有启动？先执行：

bash复制systemctl status mysqld

如果服务在运行，再确认 socket 文件是否真的生成在预期路径。默认情况下 socket 会在 /tmp/mysql.sock，但如果你自定义了 my.cnf 中 socket=/var/run/mysqld/mysqld.sock，客户端仍然拿着老路径去连，自然就是找不到。还有一种情况是 /tmp 目录被清理，socket 文件消失但进程还在，此时重启 MySQL 服务通常能恢复。

不推荐用 skip-networking 来避免 IP 连接，因为这样会禁止 TCP 连接，图形工具和远程连接全都会受影响。让客户端和服务端使用统一的 socket 路径，或者干脆通过 127.0.0.1 强制走 TCP，都能绕过这种路径不匹配的尴尬。

6.2 Navicat 连接不上：认证插件问题排在最前面

搜“navicat 连接 mysql”的技术帖非常多，原因之一就是 Navicat 版本与 MySQL 8.0 默认认证机制不兼容。报错信息通常包含 Authentication plugin 'caching_sha2_password' cannot be loaded。

最直接的解决思路是把应用用户改为 mysql_native_password：

sql复制ALTER USER 'root'@'localhost'
IDENTIFIED WITH mysql_native_password BY '你的密码';
FLUSH PRIVILEGES;

但这不是我在新项目上推荐的做法，因为 MySQL 官方已经逐步淘汰旧插件，升级到最新版 Navicat 或者换用官方 MySQL Workbench、DBeaver，通常就能原生支持新认证。

排查顺序应该是这样：先看 MySQL 服务是否监听 3306，再看防火墙是否放行，然后看用户表是否允许目标主机登录，最后才是认证插件兼容性。很多人只看报错信息就认定是密码错了，实际上 Host '192.168.x.x' is not allowed to connect 和密码错误、认证插件错误是三个完全不同的问题。

6.3 忘记 root 密码的完整自救流程

“mysql 忘记数据库密码怎么办”实际上是一个可以标准化的恢复流程。MySQL 8.0 最常见的恢复步骤如下：

停掉 MySQL 服务：
```
bash复制sudo systemctl stop mysqld
```

以跳过授权表的方式启动：

bash复制sudo mysqld_safe --skip-grant-tables &

直接无密码登录：
```
bash复制mysql -u root
```
刷新权限并修改密码。注意 8.0 中要先 FLUSH PRIVILEGES 再改密码，否则会因为权限表未重新加载而提示权限不足：
```
sql复制FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewStrongPassword';
FLUSH PRIVILEGES;
```
重启服务，正常登录。

需要提醒的是，--skip-grant-tables 模式下，任何人不需要密码就能连上数据库，所以必须确保这个状态只在本机短暂使用，操作完成立即恢复正常的认证并重启服务。如果不确定进程是否残留，用 ps -ef | grep mysqld 检查一遍再启动正式服务。

再分享一个我偏爱的习惯：新建一个专门用于日常操作的普通用户，把 root 只当作紧急救援账号，不放进任何应用配置。这样做之后，即使应用配置泄露，数据库损失也不是毁灭性的。绕密码这种事偶尔救一次急就好，真正规范的最小权限和用户分权，才是在创建 MySQL 之后最应该长期经营的事。