装 MySQL 这件事看起来是入门第一课但我在真实环境里见过的翻车八九成都发生在这第一课上。有人照着某篇三年前的帖子敲完命令systemctl start mysqld转半天没反应有人装完能进本地命令行同事从自己电脑连过来却报Cant connect to MySQL server on xxx.xxx.xxx.xxx还有人升级到 8.0 之后老版本的客户端工具直接提示认证插件不支持。这些问题的根子不在 SQL 写得对不对而在安装方式、认证插件、监听地址、系统服务管理这几个环节上。这篇就按我自己的习惯把 Linux 下 MySQL 的安装、初始化、基础使用和排错顺序完整走一遍涉及 CentOS/RHEL 系的 rpm 包管理和 Ubuntu/Debian 系的 deb 包管理两条线同时把建库建表、增删改查、排序规则、中文乱码这些日常操作一起串起来。如果你刚开始接触数据库课程设计或者需要在服务器上给项目搭一套本地库这篇里的命令可以直接抄如果你已经装过几次但总在某个环节卡壳重点看第 3 章和第 6 章。1. 装之前先理清三件事发行版、源、以及系统里是否已经躺着一个MySQL的近亲很多人拿到服务器第一件事就是搜一条安装命令贴进去这是最容易返工的做法。安装前把下面三个问题搞清楚后面能省掉至少半小时的排错时间。1.1 发行版决定了你敲的是 yum 还是 apt这不是口味问题而是包的格式和路径都不一样。RHEL、CentOS、Rocky、AlmaLinux、Fedora 这一系用 RPM 包包管理器是yum或dnfDebian、Ubuntu、Linux Mint 这一系用 DEB 包包管理器是apt。判断方法很简单终端里敲一条cat /etc/os-release输出里的ID和VERSION_ID就是你的身份证明。别小看这一步我见过有人在 Ubuntu 上按 CentOS 的教程去下.rpm包然后拿rpm -ivh硬装最后系统里两套库文件打架卸载都卸不干净。还有一个隐藏坑很多发行版默认已经装了一个 MySQL 的兼容分支。CentOS 7/8 上默认的mariadb-libsUbuntu 上可能预装的mariadb-server它们占用同样的端口、同样的 socket 路径、同样的配置文件目录。如果你不先清掉装 MySQL 时会出现端口被占、服务名冲突、/etc/my.cnf被覆盖等一连串问题。所以第 1.3 节的检查清单务必过一遍。1.2 三种安装方式的取舍官方源、系统自带源、二进制包这是安装前最该想清楚的一件事因为三种方式的后续维护成本差别很大。方式优点缺点适用场景官方 YUM/APT 仓库版本新、升级方便、依赖自动处理、有官方支持需要联网拉取仓库配置下载速度受网络影响绝大多数生产与学习环境首选发行版自带源一条命令搞定不需要额外加源版本偏旧CentOS 7 自带源里可能是 5.5/5.7 甚至 MariaDB对版本没要求、只做临时测试官方二进制 tar 包版本完全可控可自定义安装路径不需要 root 装包依赖要手动装初始化、服务脚本、环境变量全要自己配需要多版本共存、或没有 root 权限的场景对绝大多数人我的建议是走官方仓库。理由很直接官方仓库解决了依赖关系systemctl服务脚本是现成的mysql客户端、mysqldump、mysqladmin这些工具一次性到位后续小版本升级一条yum update mysql-server就完事。二进制 tar 包看起来干净可控但新手用它经常卡在libaio、numactl缺失、mysqld找不到 socket、没有开机自启这些琐碎问题上学习成本远高于收益。如果你确实在离线环境或者内网环境官方仓库拉不下来可以用国内的镜像站点同步 RPM/DEB 包或者用二进制 tar 包。这时候要额外注意的是先手动把libaio、numactl-libs、ncurses这几个底层依赖装好否则mysqld启动时会直接报共享库找不到。1.3 装之前必须过的五项检查这五项检查我基本是条件反射每次开新机器都会走一遍加起来不超过两分钟。第一检查是否已存在 MySQL 或 MariaDB。执行rpm -qa | grep -i -E mysql|mariadb或dpkg -l | grep -i -E mysql|mariadb。如果有输出先决定是卸载还是保留。卸载时要连数据目录一起清理不然重新装的时候旧数据会干扰初始化# RPM 系 rpm -qa | grep -i mariadb yum remove mariadb-libs rm -rf /var/lib/mysql /etc/my.cnf /var/log/mysqld.log # DEB 系 apt purge mariadb-server mariadb-client rm -rf /var/lib/mysql /etc/mysql第二检查 3306 端口是否被占。ss -lntp | grep 3306或老一点的系统用netstat -lntp | grep 3306。如果已经被别的进程占了要么先把那个进程停掉要么规划一个别的端口别装完才发现起不来。第三检查磁盘空间。MySQL 的数据目录默认在/var/lib/mysql这个分区至少留出 10GB 以上的余量。df -h /var看一眼别等到装完写数据时报No space left on device。我在一台小内存云主机上见过/var只给了 8GB装完系统就剩不到 2GBMySQL 初始化直接失败。第四看内存。MySQL 8.0 默认的innodb_buffer_pool_size是 128MB1GB 内存的机器能跑起来但会非常吃力。如果你的机器内存小于 2GB安装后第一件事就是把缓冲池调小具体在第 3.4 节会讲。第五确认系统时间和字符集。date看一眼时区对不对locale看一眼当前语言环境。这两项出问题会在日志时间戳和中文排序上给你添麻烦。2. 走官方仓库装 MySQL 8.0从加源到看到3306端口在监听前置检查过了正式开工。这一章按 RPM 系为主线DEB 系的差异我在对应位置单独标出来。2.1 加源这一步为什么要校验 GPG key以 CentOS/RHEL 8 为例官方仓库的做法是下载一个仓库配置包然后安装# 下载官方仓库配置包版本号随官方更新具体文件名以官网为准 curl -O https://dev.mysql.com/get/mysql80-community-release-el8-9.noarch.rpm # 安装它这一步会自动把 mysql 的 yum 源写进 /etc/yum.repos.d/ rpm -ivh mysql80-community-release-el8-9.noarch.rpm # 检查源是否生效 yum repolist enabled | grep mysqlDebian/Ubuntu 的做法是先下载一个配置 deb 包安装时会弹出一个交互界面让你选版本选MySQL 8.0然后apt updatewget https://dev.mysql.com/get/mysql-apt-config_0.8.33-1_all.deb sudo dpkg -i mysql-apt-config_0.8.33-1_all.deb sudo apt update这里有个容易被忽略的细节仓库配置包里带了官方的 GPG 公钥用来校验后续下载的软件包来源是否可信。如果你看到Public key for mysql-community-server-xxx.rpm is not installed这类报错说明校验没通过仓库缓存里的包被判定为不可信安装会被直接拒绝。正确的处理方式是手动导入官方公钥rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2023 # 或者针对某个包 rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql有人图省事直接加--nogpgcheck跳过校验这在私有测试环境无所谓但在任何正式环境都不该这么干——跳过校验等于放弃了对包完整性的最后一道把关。顺手清一下缓存再装避免拿到旧的元数据yum clean all yum makecache2.2 安装组件不是只装server还有几个常被漏掉的新手最容易犯的错是只装mysql-server然后发现mysql命令行敲不出来或者装了数据库但没有任何客户端工具。yum install -y mysql-community-server mysql-community-client mysql-community-common mysql-community-libs这几个组件各自的职责mysql-community-server核心服务端包含mysqld进程和数据目录初始化脚本。mysql-community-client命令行客户端包括mysql、mysqladmin、mysqldump。mysql-community-common字符集定义、错误消息文件等共享资源缺了它服务端起不来。mysql-community-libs客户端库如果后面要写程序连数据库编译时需要它。Debian/Ubuntu 对应的包名是mysql-server、mysql-client、mysql-common。安装过程在 deb 系下会自动初始化数据目录并启动服务不需要手动initialize这是两个系统的一个明显差异。装完之后建议验证一下版本确认装的是不是你要的那个mysqld --version mysql --version2.3 首次启动初始密码藏在错误日志里RPM 系在安装完成后不会自动启动服务需要手动来。而且 MySQL 5.7 之后安装包首次初始化时会生成一个随机的临时密码存在错误日志里不是空密码。systemctl start mysqld systemctl status mysqld # 找临时密码 grep temporary password /var/log/mysqld.log输出通常长这样2024-05-12T03:21:47.123456Z 6 [Note] [MY-010454] [Server] A temporary password is generated for rootlocalhost: k8Rt!pQ2wZx冒号后面那串就是。用它登录mysql -u root -p这里有个很常见的误解如果错误日志里没有temporary password这一行不代表初始化失败。可能是数据目录已经存在比如你之前装过又卸载不彻底MySQL 跳过了初始化步骤。这时候先确认/var/lib/mysql是不是空的不是的话要么清干净重来要么用已有的密码登录。另一种可能是你在安装前手动执行过mysqld --initialize-insecure那 root 就是空密码。Debian/Ubuntu 的路径完全不同服务名是mysql而不是mysqld错误日志在/var/log/mysql/error.log而且默认情况下 Ubuntu 的 root 用户用的是auth_socket认证插件只能通过本地 socket 用系统 root 身份免密登录不涉及临时密码这一套。2.4 服务管理的高频命令与开机自启装完只是开始日常运维要跟服务打交道。把这几个命令记熟出问题时能省很多事systemctl start mysqld # 启动 systemctl stop mysqld # 停止 systemctl restart mysqld # 重启 systemctl enable mysqld # 开机自启 systemctl disable mysqld # 取消开机自启 systemctl is-enabled mysqld # 查看是否自启有个细节值得强调restart和reload不是一回事。reload也就是systemctl reload mysqld实际执行的是mysqladmin reload只重新读取部分可在运行时生效的参数比如权限表而innodb_buffer_pool_size、port、datadir这些参数改了必须restart才能生效因为要重新加载存储引擎和重新绑定端口。我在一台机器上改完端口后只reload然后一直奇怪为什么还是连的旧端口白白排查了二十分钟。另外enable和start是两码事enable只是设置了开机自启的符号链接不会立刻启动服务。生产机器上装完记得两件都做。3. 第一次登进去之后账号安全、认证插件与几个该改的参数能登录不代表能放心用。这一章讲的是登录之后立刻该做的事顺序很重要。3.1 mysql_secure_installation 实际动了哪些东西几乎所有教程都会让你跑这个脚本但很少有人讲清楚它到底改了啥。整个过程分六步每一步的含义如下设置 root 密码如果你想换掉临时密码就在这里改。注意 MySQL 8.0 默认的密码策略要求至少 8 位且包含大小写字母、数字、特殊字符四类中的三类。是否移除匿名用户选 Y。匿名用户是没有用户名的账号允许任何人免密登录属于历史遗留的安全隐患。是否禁止 root 远程登录选 Y除非你有明确的远程 root 需求但即使有也该用专用账号代替。是否删除 test 数据库选 Y。这是默认创建的测试库任何用户都能访问没必要留着。是否立即刷新权限表选 Y。脚本结束时提示配置完成。跑完后建议验证一下密码策略避免以后建账号时被规则卡住SHOW VARIABLES LIKE validate_password%;如果你在纯学习环境觉得密码规则太啰嗦可以临时调低SET GLOBAL validate_password.policy LOW; SET GLOBAL validate_password.length 6;这里我必须提醒一句这个修改在重启后失效而且它是全局的会影响同一实例上所有账号的密码强度要求别在生产库上随手执行。3.2 caching_sha2_password老客户端连不上的真正原因这是升级到 8.0 之后最高频的一个疑难杂症。现象是命令行mysql -u root -p能进但用某些图形化客户端或老版本的编程语言驱动连接时报错信息大致是Authentication plugin caching_sha2_password cannot be loaded根本原因在于认证插件的默认值变了。MySQL 5.7 的默认插件是mysql_native_password8.0 换成了caching_sha2_password安全性更高但配套的客户端必须支持新的握手协议。老版本客户端只认老的协议握手阶段就被拒。三种解决思路各有取舍方案操作优点缺点升级客户端换成新版驱动或客户端工具最彻底安全性不降级依赖项目其他组件的兼容性单个账号改回老插件ALTER USER ... IDENTIFIED WITH mysql_native_password BY ...改动范围小只影响一个账号该账号安全性降低修改服务端默认插件在my.cnf里设default_authentication_plugin一次配置全局生效影响所有新建账号需要重启单账号改写的语句长这样ALTER USER appuser% IDENTIFIED WITH mysql_native_password BY App2024pass; FLUSH PRIVILEGES;我的建议是优先升级客户端实在升级不了再针对具体账号降级插件而不要全局改服务端配置。理由是全局面配置是个遗忘陷阱——半年后有人在这台实例上建新账号看到默认插件是老的就以为这台机器是老版本排查方向全跑偏。3.3 别拿root跑业务专用账号的授权粒度mysql -u root -p能解决问题但绝不该出现在应用的配置文件里。root 拥有包括DROP DATABASE、GRANT、SHUTDOWN在内的全部权限一旦应用侧被拖库或者配置文件泄露损失是不可控的。正确的做法是按用途拆账号权限只给到够用为止CREATE USER appuser192.168.1.% IDENTIFIED BY App2024pass; GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO appuser192.168.1.%; CREATE USER report% IDENTIFIED BY Report2024pass; GRANT SELECT ON shop.* TO report%; FLUSH PRIVILEGES;这里有几个实战要点值得展开。第一主机部分不要图省事写成%。%表示任意主机包括公网来源能限定网段的就限定网段。第二权限范围要具体到库甚至表。我见过有运维图方便给业务账号授了ALL PRIVILEGES ON *.*这等于给了它整个实例的生杀大权。第三FLUSH PRIVILEGES在用了CREATE USER/GRANT语句之后其实不是必需的因为这类语句本身就会更新内存中的权限表只有直接改mysql.user表这种操作才必须刷新。想看某个账号到底有哪些权限用SHOW GRANTS FOR appuser192.168.1.%;3.4 my.cnf里我一般会先动的几个值装完就调参数不是必须的但有几个值我习惯在初始化阶段就定下来因为它们影响后续所有数据的存储方式改了成本高。字符集。8.0 的默认字符集已经是utf8mb4了这比 5.7 那个需要手动设的utf8好太多。但如果你从旧环境迁过来务必确认配置文件里没有被写成utf8在 MySQL 里utf8是utf8mb3的别名只支持 3 字节存不了 emoji 和部分生僻汉字。[mysqld] character-set-server utf8mb4 collation-server utf8mb4_0900_ai_ci [client] default-character-set utf8mb4InnoDB 缓冲池。默认 128MB在 4GB 内存的机器上可以提到 1GB 左右一般是物理内存的 50%~70%专机专用的情况下。这个值调大能显著减少物理 IO。innodb_buffer_pool_size 1G最大连接数。默认 151并发一高就报Too many connections。但也不能无脑调大每个连接都占内存调到 500 还算合理1000 以上就要考虑是不是该上连接池了。max_connections 500慢查询日志。这个我强烈建议一开始就开排查性能问题时它是第一手资料slow_query_log 1 slow_query_log_file /var/log/mysql-slow.log long_query_time 2改完配置记得确认两件事一是配置文件路径对不对RPM 系通常是/etc/my.cnfDEB 系是/etc/mysql/mysql.conf.d/mysqld.cnf而且 DEB 系的加载顺序有讲究后面加载的文件会覆盖前面的二是重启后验证参数是否真的生效用SHOW VARIABLES LIKE innodb_buffer_pool_size;看一眼别只改文件不验证。4. 在命令行把库表数据跑通字符集、排序规则与增删改查环境搭好了接下来才是真正的日常操作。这一章把建库建表到增删改查走一遍重点讲那些教程里一句话带过、实际会踩的地方。4.1 建库建表前先把字符集和排序规则定下来创建数据库时指定字符集是防止后面中文乱码最有效的一步CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_0900_ai_ci;utf8mb4_0900_ai_ci里的0900指的是基于 Unicode 9.0 的排序规则ai是 accent insensitive重音不敏感ci是 case insensitive大小写不敏感。这意味着SELECT * FROM t WHERE name Alice能匹配到aliceé和e视为等价。如果你需要区分大小写可以换成utf8mb4_0900_as_cs但绝大多数业务场景不需要。建表时也显式指定一次不依赖库的默认值USE shop; CREATE TABLE product ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 商品名称, price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 售价, stock INT NOT NULL DEFAULT 0 COMMENT 库存, category_id INT UNSIGNED DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_0900_ai_ci;几个建表时的经验点。主键用INT UNSIGNED而不是INT正数范围翻倍业务 ID 用不到负数。金额用DECIMAL而不是FLOAT/DOUBLE浮点数会有精度误差0.10.2 在浮点世界里不等于 0.3金额算错是要出事的。created_at设DEFAULT CURRENT_TIMESTAMP插入时不传这个字段就自动填当前时间少写一个字段少一个出错机会。索引不是越多越好每个索引都要占用空间、拖慢写入速度只给查询条件里真正会用到的列建。4.2 增删改查四种写法的实际演练插入数据推荐显式列出字段名不要依赖字段顺序INSERT INTO product (name, price, stock, category_id) VALUES (机械键盘, 399.00, 50, 1), (无线鼠标, 129.50, 120, 1), (显示器支架, 259.00, 30, 2), (USB集线器, NULL, 0, 2);一次插入多行的写法比写四条单行 INSERT 效率高得多SQL 解析和事务提交的开销只付一次。注意第四条我故意把price写成了NULL——虽然建表时设了NOT NULL DEFAULT 0.00但显式传NULL到NOT NULL列会被拒绝报Column price cannot be null。这是个好设计能把脏数据挡在门外但你要清楚这个行为。查询数据最基础的形态SELECT id, name, price, stock FROM product WHERE stock 0 ORDER BY price DESC LIMIT 10;更新数据WHERE 条件必须是唯一性足够的字段UPDATE product SET stock stock - 5, price 389.00 WHERE id 1;这条语句里stock stock - 5是利用原值做自减这种写法在并发场景下依赖行锁保证正确性比先查出来再写回去安全。但如果是先 SELECT 得到库存 50代码里判断大于 5再 UPDATE 设为 45这种两步走并发下就会超卖——这是业务代码的坑不是 SQL 的坑但我想借这个机会点一句。删除数据务必先 SELECT 确认范围-- 先看看要删哪些 SELECT * FROM product WHERE stock 0 AND created_at 2024-01-01; -- 确认无误再删 DELETE FROM product WHERE stock 0 AND created_at 2024-01-01;我个人的习惯是任何 DELETE 和 UPDATE 都先在事务里跑一遍看影响行数对不对START TRANSACTION; DELETE FROM product WHERE stock 0 AND created_at 2024-01-01; -- 看返回的 Rows matched / Changed ROLLBACK; -- 确认无误再改成 COMMIT这个习惯救过我至少两次。有一次 WHERE 条件少写了一个限制影响行数从预期的几十变成几万ROLLBACK一敲数据完好无损。4.3 ORDER BY的排序行为与NULL值的位置排序看起来简单实际有几个反直觉的地方。我们先用一组数据演示INSERT INTO t_score (name, score) VALUES (A, 90), (B, NULL), (C, 75), (D, NULL), (E, 90); SELECT name, score FROM t_score ORDER BY score ASC;结果里两条NULL会排在最前面。原因是MySQL 认为 NULL 比其他任何值都小升序时自然排最前。如果你希望 NULL 排在最后有两种写法-- 写法一把 NULL 当成一个大值 SELECT name, score FROM t_score ORDER BY score IS NULL, score ASC; -- 写法二利用 -score 取反数字类型适用 SELECT name, score FROM t_score ORDER BY -score DESC;写法一的原理是score IS NULL这个表达式返回 0 或 1先按这个排序非 NULL 的排前面同组内再按 score 升序。这是最通用、也最容易理解的写法。还有一个多列排序的稳定性问题。ORDER BY score DESC里如果有并列值上面 A 和 E 都是 90它们的相对顺序是不确定的可能这次 A 在前下次 E 在前。要让结果稳定可复现必须加一个唯一的次级排序字段SELECT name, score FROM t_score ORDER BY score DESC, id ASC;分页场景下这个细节尤其重要。LIMIT 0,10和LIMIT 10,10如果排序不稳定同一条记录可能在两页里都出现或者在两页里都不出现——用户看到的就是翻页时少了一条其实是排序不稳定导致的假象。4.4 Linux终端下中文乱码的两条排查线索在 Windows 上很少遇到但在 Linux 终端敲 SQL 时中文显示成问号或乱码我遇到过好几次。判断思路分两条线。第一条线看服务端和客户端的字符集设置是否一致。进 MySQL 后执行SHOW VARIABLES LIKE character_set%; SHOW VARIABLES LIKE collation%;重点关注四个值character_set_client客户端发来的编码、character_set_connection连接层编码、character_set_results返回给客户端的结果编码、character_set_server服务端默认编码。这四个只要有一个不是utf8mb4中文就可能出问题。第二条线看终端本身的编码。执行echo $LANG和locale如果输出里是C或POSIX说明终端是 ASCII 环境中文本身就显示不了。临时切换到 UTF-8export LANGen_US.UTF-8或者登录时显式指定客户端编码mysql -u root -p --default-character-setutf8mb4还有一个更隐蔽的情况表本身的字符集和连接字符集不一致。表建的时候用了latin1连接层是utf8mb4这时候数据看起来能插进去但实际存的是被转换过的字节。查一下表的定义就能发现SHOW CREATE TABLE product\G如果末尾是DEFAULT CHARSETlatin1那这个表就是隐患。修正的语句是ALTER TABLE product CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;但这条语句在大表上会锁表并重建数据执行前务必评估影响。5. 让外部工具连上它远程访问、图形客户端与备份导出本机能连只是第一步很多时候还需要同事连过来查数据或者用图形化工具操作。这一章讲远程访问的开启条件、客户端的连接参数以及备份的基本手段。5.1 放开远程访问需要同时满足的三个条件只改一个地方是连不上的这是我见过最多的误解。远程访问要同时满足下面三个条件缺一不可条件一监听地址不能只绑本地回环。默认情况下 MySQL 只监听127.0.0.1其他机器根本感知不到这个端口。检查一下SHOW VARIABLES LIKE bind_address;如果值是127.0.0.1需要在配置文件里改成0.0.0.0监听所有网卡或者具体的网卡 IP[mysqld] bind-address 0.0.0.0改完必须systemctl restart mysqld才能生效。这里我建议不要直接用0.0.0.0如果你的服务器有多张网卡比如一张公网、一张内网绑到内网那张网卡的 IP 上更安全。条件二账号的允许来源主机要匹配。appuserlocalhost这个账号只能从本机连远程来的一律拒绝。要允许 192.168.1.0/24 网段得建对应的账号或者修改现有账号CREATE USER appuser192.168.1.% IDENTIFIED BY App2024pass; GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO appuser192.168.1.%;注意 MySQL 的权限匹配规则里%是通配符但它不匹配localhost。也就是说appuser%这个账号从本机用-h 127.0.0.1可以连用-h localhost可能匹配到的是appuserlocalhost那条记录。这种细节在排查为什么本机能连远程不能连或者反过来的时候特别重要。条件三防火墙要放行端口。firewalld环境firewall-cmd --permanent --add-port3306/tcp firewall-cmd --reload firewall-cmd --list-portsufw环境Ubuntu 常见ufw allow 3306/tcp ufw status云服务器还有一个额外环节安全组。这是云平台层面的虚拟防火墙和系统内的firewalld是两层独立的过滤。我见过不少人把系统防火墙关了还是连不上就是因为安全组没配。5.2 图形化客户端连接时的几个参数怎么填图形客户端的选择上官方有 MySQL Workbench开源社区还有一些通用型的数据库管理工具。填连接信息时涉及几个参数参数典型值说明Host192.168.1.100服务器 IP不是 localhostPort3306与服务端port参数一致Userappuser建议用专用账号不用 rootPassword-对应账号的密码Default Schemashop连接后默认进入的库如果客户端支持 SSH 隧道方式连接那又是另一种配置思路先通过 SSH 连到服务器再从服务器本地连数据库这样数据库端口甚至不需要对公网开放。这种方式在安全要求较高的环境里很常见。连接失败的排查顺序我的习惯是先排除最简单的可能能不能 ping 通排除网络层端口通不通用telnet 192.168.1.100 3306或者nc -vz 192.168.1.100 3306。这两个都通问题就落在账号权限或认证插件上了回到第 3.2 节和 5.1 节的内容。5.3 mysqldump是Linux下最省事的备份手段数据无价备份这件事在装完库的当天就该安排上。mysqldump是随客户端一起装的工具不需要额外部署。备份单个库mysqldump -u root -p --single-transaction --routines --triggers --events shop /backup/shop_$(date %Y%m%d).sql这里几个参数都有讲究。--single-transaction让备份过程在一个一致性快照里进行不锁表对 InnoDB 表尤其重要业务可以正常读写。--routines导出存储过程和函数--triggers导出触发器--events导出事件调度器——这三个不加恢复的时候会发现这些对象全没了。我最早做备份时只写了库名后来恢复到另一台机器上发现存储过程丢了才发现问题。只备份表结构mysqldump -u root -p --no-data shop /backup/shop_schema.sql恢复mysql -u root -p shop /backup/shop_20240512.sql恢复时要注意目标库必须先存在mysqldump导出的文件里通常不带CREATE DATABASE语句除非加了--databases参数。另外如果导出文件很大几个 GB 以上直接source或者重定向会比较慢可以考虑压缩导出mysqldump -u root -p --single-transaction shop | gzip /backup/shop_$(date %Y%m%d).sql.gz gunzip /backup/shop_20240512.sql.gz | mysql -u root -p shop配合crontab做定时备份是很常见的做法但千万不要只备份到同一台机器上。磁盘坏了、误删了、机器没了备份文件一起跟着走。至少要同步一份到别的存储位置。6. 出问题时的排查顺序从端口、日志到socket路径前面五章是正常流程这一章讲不正常的情况。我把这几年的排查经验整理成一个固定顺序遇到问题按这个顺序走通常十分钟内能定位。6.1 服务起不来先看错误日志而不是重启新手的第一反应是systemctl restart mysqld反复重启越重启越懵。正确做法是看日志。RPM 系的日志在/var/log/mysqld.logDEB 系在/var/log/mysql/error.log。如果不知道具体位置用mysqladmin或者查配置grep -r log-error /etc/my.cnf /etc/mysql/ 2/dev/null日志的读法是从下往上看找第一个[ERROR]。常见的几类错误和处理方式日志关键字原因处理Cant create/write to file ... (Errcode: 13)目录权限不对chown -R mysql:mysql /var/lib/mysqlAddress already in use3306 被占找出占用进程停掉或换端口InnoDB: Cannot allocate memory内存不足调小innodb_buffer_pool_sizeDifferent lower_case_table_names settings大小写敏感配置与已有数据冲突保持一致别中途改Data Dictionary initialization failed数据目录非空或残留清空/var/lib/mysql重新初始化Different lower_case_table_names这个错误特别值得说一句。Linux 上默认是 0大小写敏感Windows 上是 1不敏感。如果你从 Windows 上把数据目录整个拷到 Linux启动时就会报这个错。这个参数只能在初始化时设定事后改会破坏已有的表文件索引。所以跨平台迁移数据不要直接拷datadir用mysqldump导出再导入才是正路。6.2 3306被占用与端口冲突的处理端口被占的症状很明确systemctl status mysqld显示failed日志里有Address already in use。找占用者ss -lntp | grep 3306 # 或者 lsof -i :3306输出的最后会显示进程名和 PID。如果占用者是另一个 MySQL 实例或者残留进程kill掉再启动。如果是个不能停的业务进程那就只能给 MySQL 换端口[mysqld] port 3307换完端口别忘了同步改防火墙规则和客户端的连接配置。这里还有一种很隐蔽的情况服务显示启动成功但用mysql -u root -p连不上报Cant connect to local MySQL server through socket。这通常不是端口问题而是 socket 路径问题见下一节。6.3 socket路径不一致导致的登录失败MySQL 的本地连接有两种方式TCP 和 Unix socket。当你不指定-h时Linux 下默认走 socketsocket 文件路径由socket参数决定。问题出在客户端和服务端各自读到的 socket 路径不一样。比如服务端配置在/var/lib/mysql/mysql.sock但客户端默认去找/tmp/mysql.sock就会报ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock (2)排查方法# 看服务端实际用的 socket 路径 mysqladmin -u root -p variables | grep socket # 或者从进程信息里看 ps aux | grep mysqld | tr \n | grep socket解决方式有两种任选其一一是登录时显式指定-Smysql -u root -p -S /var/lib/mysql/mysql.sock二是在[client]段里也配上同样的路径让客户端默认就能找对[client] socket /var/lib/mysql/mysql.sock或者干脆强制走 TCPmysql -u root -p -h 127.0.0.1 -P 3306注意-h 127.0.0.1和-h localhost在 MySQL 里是不同的前者走 TCP后者走 socket。这个差别在排查问题时经常是决定性的。6.4 磁盘写满之后MySQL会表现出什么症状这是最容易被误判的一类故障。磁盘满了之后MySQL 的表现往往是能连上但一写就报错或者干脆连都连不上而错误信息五花八门不直接提磁盘。典型症状有这么几种写入时报ERROR 1114 (HY000): The table xxx is full日志里出现Disk is full writing服务启动时卡在 InnoDB 恢复阶段然后失败严重的情况下mysql客户端连 socket 都建不出来因为建 socket 文件也需要写磁盘。排查第一步永远是df -h看/var或者数据目录所在分区是不是 100%。确认是磁盘问题后处理顺序是先清理能清的旧日志、临时文件、/tmp下的废弃文件腾出空间让服务先能正常起来然后清理二进制日志PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);binlog是磁盘空间的隐形消耗大户尤其在写入频繁的实例上几天就能涨到几十个 GB。如果你不需要主从复制或者按时间点恢复可以在配置文件里限制它的保留时间[mysqld] binlog_expire_logs_seconds 604800这个值是 7 天的秒数。设置之后超过 7 天的binlog会自动清理。我在一台测试机上遇到过更极端的/var分区满了导致mysqld无法写入pid文件systemctl start等了 90 秒后超时失败日志里只有一行Timed out waiting for...完全看不出是磁盘问题。后来是df -h一步步往下看才发现/var的占用率是 100%。所以我现在养成习惯MySQL 出任何异常df -h和free -m这两条命令先敲一遍成本几秒钟。到这里从装库、初始化、建表、增删改查到远程访问、备份和故障排查一条完整的链路就走完了。实际用起来你会发现真正的难点从来不在 SQL 语法上而在这些环境配置和边界情况的处理上。我自己的经验是新机器装完 MySQL 之后立刻做三件事跑一遍mysql_secure_installation、建一个限定网段的业务账号、配好定时备份。这三件事花不到十分钟但能在后面省下无数个加班的晚上。