1. 摸清目录结构一条命令定位所有关键路径接手一台机器上的 MySQL 实例大多数人的第一反应是看配置文件但我更习惯先弄清楚它的目录结构。原因很简单配置文件可以被拆成好几份、可以藏在意料之外的位置甚至可能根本没生效而目录结构是客观存在的安装目录在哪里、数据目录在哪里、日志写到哪里、临时文件落在哪块盘上这些信息会直接决定后面所有的操作方式。MySQL 目录结构与配置文件这两件事实际上是同一个问题的两个侧面前者告诉你“东西放在哪”后者决定“东西怎么跑”。你先把这两件事弄清楚后面调参数、迁数据、扩容磁盘、排查启动失败才有稳定的判断依据。这篇内容想解决的就是这么几个具体问题装完之后那些看着陌生的目录分别负责什么一台机器上可能存在多份配置文件最终生效的是哪一份配置里的数字该怎么算才不至于凭感觉写以及自定义目录部署、数据目录搬迁这类高频操作具体到命令层面应该怎么走。适合已经能连上 MySQL、但每次遇到“改了参数没反应”“启动报错找不到文件”就心里没底的同学也适合需要给团队定一套部署规范的同学。下面这些内容不依赖某个特定的云环境或发行版命令以 Linux 为主Windows 的差异我会单独标出来。1.1 别急着改配置先问清楚“装在哪、数据在哪”判断一台实例的目录布局我最常用的方式是三条查询加一条命令行通常十几秒就能摸清全部情况。在已经连上实例的前提下依次执行SELECT basedir;、SELECT datadir;、SHOW VARIABLES LIKE tmpdir;这三条就能把安装目录、数据目录、临时目录三个关键路径全部拿到。这三个值全部来自实例自身的运行期变量比去翻文件系统可靠得多因为它们反映的是这个进程实际使用的路径而不是某个配置文件里写的“打算使用的”路径。临时目录这个值经常被忽略。MySQL 在执行排序、建立临时表、处理大查询时会往tmpdir写文件如果它落在系统盘或者一个容量很小的分区上那么一条没有走索引的大查询就足够把机器拖垮。我曾经处理过一个现象很别扭的案例实例整体运行正常但只要跑报表就报错退出翻了半天配置才发现临时目录和小容量系统盘在同一块设备上。把tmpdir单独指到一块大容量数据盘之后问题当场消失。所以你在勘察阶段就把这个值一并记下来后面规划磁盘时会省很多事。命令行这一侧ps -ef | grep mysqld能直接看到启动进程的完整参数重点看有没有--defaults-file、--datadir、--socket这几个显式参数。很多时候配置文件里写的是 A启动脚本里用--defaults-file指定的是 B这种“两份配置打架”的情况排查起来非常费时间。另外对于通过包管理器安装的环境systemctl status mysql或者systemctl cat mysqld能看到服务单元文件里实际传入的参数这一步能帮你确认真正的入口在哪。注意如果实例是别人搭好交接给你的在改动任何配置之前务必先用上面这套方法记录一份“现状快照”包括三个路径、版本号、端口、socket 路径、配置文件位置。这份快照在出现回滚需求时价值极高尤其是版本号因为不同版本对同名参数的解释可能完全不同。1.2 安装目录里的三块核心区域bin、lib、share安装目录basedir本身不存业务数据但它决定了这个实例能用哪些工具、加载哪些插件、报错信息从哪里来。这个目录下有四个子目录值得单独说清楚。bin是最常打交道的地方。除了mysqld本体服务端的运维工具几乎都在这里mysqldump做逻辑备份mysqlbinlog解析二进制日志mysqladmin做状态查询和关库mysql是客户端mysqlcheck做表检查mysql_secure_installation用于初始化后的安全加固。这些工具全部共用同一套客户端库所以它们的版本和mysqld的版本是一致的这意味着你在做跨版本迁移时不能拿老版本的mysqldump去导新版本实例的数据反过来也一样。lib下面最需要关注的是插件目录通常是lib/plugin或者lib/mysql/plugin。这个路径对应参数plugin_dir你编译或者以二进制方式安装的存储引擎、审计插件、密码校验插件都要放到这个目录里然后在配置里用plugin-load-add加载。插件加载失败最常见的原因就是文件放错了目录或者文件权限不允许mysqld进程读取。share目录里放着错误信息文件和 SQL 帮助表数据对应参数lc_messages_dir。这个东西平时没人关注但它有个实际影响如果你发现错误日志里的提示信息全是英文想在配置里把lc_messages改成别的语言却发现不生效那多半是share目录下根本没有安装对应语言的错误信息文件。包管理器安装的版本通常只带了英文需要额外安装语言包。support-files是个容易被低估的目录里面通常有配置文件模板my.cnf的各种预设版本、mysqld_multi多实例管理脚本以及 systemd 单元文件样例。做自定义部署时我一般直接从这里拷一份模板作为起点比自己从空白文件开始写更稳妥因为模板里已经包含了一些发行版相关的默认路径。1.3 数据目录才是真正的现场文件清单与职责数据目录datadir是真正需要重点保护的地方。这个目录里同时存放着表数据、日志、状态文件理解每个文件的职责在磁盘告警或者启动失败时能帮你快速定位到底是哪类文件导致的。下面把常见文件按功能归类列清楚。文件或目录职责可删除性备注ibdata1InnoDB 系统表空间绝对不能删存放数据字典、回滚段相关结构、双写缓冲等mysql.ibd8.0 的数据字典表空间绝对不能删8.0 把系统表数据合并到了这里*.ibd独立表空间一表一文件不能删开启innodb_file_per_table时每张表一个undo_001、undo_002回滚表空间不能直接删由innodb_undo_tablespaces管理#innodb_redo8.0.30 之后的 redo 日志目录不能删里面是 32 个固定大小的 redo 文件ib_logfile0、ib_logfile18.0.30 之前的 redo 日志不能删老版本按innodb_log_files_in_group数量存在ibtmp1临时表空间可重建重启后重建异常膨胀时重启即可回收binlog.000001及索引二进制日志按保留策略清理不要用 rm 直接删用PURGE BINARY LOGSauto.cnf实例唯一标识删了会重新生成复制环境里用错会导致主从异常*.pemTLS 证书与私钥可重新生成8.0 初始化时自动生成*.pid进程号文件可删异常退出后残留会导致启动判断出错*.sockUnix socket 文件可删路径由socket参数决定*.err或错误日志错误日志按需轮转排查问题的第一现场mysqld-auto.cnf持久化动态参数不建议手改SET PERSIST写入的 JSON 文件这张表里我最想强调两行。第一行是auto.cnf这个文件里存的是实例的 UUID复制链路靠它区分不同的实例。有些同学为了“重新初始化”把数据目录清空但忘了这个文件或者从别的机器整目录拷贝过来带着别人的 UUID结果从库连上去就报错而且错误信息往往不会直接指向这个问题。第二行是ibtmp1这个文件在跑过几个大查询之后可能涨到几十 GB而且只在重启时才会被回收不重启的话它不会自己缩小。磁盘告警时先看一眼这个文件能省下不少排查时间。数据目录下还有一个需要注意的结构每个业务库对应一个同名子目录库里每张表对应一个.ibd文件加一个同名的.frm文件5.7 及以前8.0 之后表结构信息合并进了数据字典子目录里只剩.ibd。所以你在做单表的数据文件级拷贝时8.0 和 5.7 的操作方式不一样混着来会出问题。1.4 权限与文件系统最容易被忽视的两处坑数据目录的权限设置有一套约定俗成的做法但坑也集中在这里。常规的权限是datadir归mysql用户和mysql组所有目录权限750文件权限640左右。之所以强调这一点是因为mysqld启动时是以mysql用户身份运行的如果数据目录属于root或者中间某一层目录缺少执行权限进程直接起不来而错误日志里给出的信息经常只有一句“无法创建或写入文件”看不出具体是哪一层的问题。我在实际排查中形成的一个习惯是遇到启动失败先别急着改配置用sudo -u mysql ls -ld沿着数据目录一路往上逐层检查一遍从根目录到datadir的每一层都要有执行权限。曾经有一个案例折腾了很久最后发现是新加的磁盘挂载点权限是700且属主为rootdatadir本身权限完全正确但父目录挡住了。这种问题光看datadir的属性是看不出来的。第二处坑是文件系统类型。放数据目录的分区我从来不用网络文件系统。原因不是性能问题而是文件锁语义在这种文件系统上不可靠InnoDB 依赖文件锁来保证同一份数据不被两个进程同时打开锁语义出问题会导致数据损坏。另外也不要放在内存文件系统上虽然速度快但机器一重启数据就全没了。放到只读挂载的分区上自然也不行这种错误在启动时会立刻暴露属于比较好排查的类型。提示datadir所在分区建议预留出比当前数据量更大的空间因为 redo 日志、二进制日志、临时表空间都会和它抢同一块盘。如果条件允许把二进制日志单独指到另一块盘既减少 IO 竞争也让日志清理和备份互不影响。还有一个常被忽略的细节磁盘的预分配策略和datadir上的文件删除行为。InnoDB 的表空间文件在删除表之后文件本身可能不会立刻缩小而是被复用。所以你会看到“删了几百 GB 的数据磁盘可用空间没变”这种现象这不是 bug是设计如此。指望靠删表来腾空间的话需要用OPTIMIZE TABLE或者重建表的方式让文件真正收缩。2. 配置文件到底读的是哪一个加载链路与优先级实测“我改了配置怎么没生效”这句话我一年能听到几十遍。绝大多数情况下不是改错了而是改的文件没被读到或者读到的顺序不对被后面的覆盖了。MySQL 的配置文件查找规则不复杂但是候选位置多加上有些路径是编译期就定死的不实测很容易判断失误。2.1 Linux 下的逐级查找规则按照官方文档给出的顺序mysqld在 Linux 上会依次检查下面这些位置对每一级只读取“第一个存在的文件”然后继续下一级越靠后读到的设置优先级越高。顺序位置说明1/etc/my.cnf最常见的位置包管理器安装时一般放这里2/etc/mysql/my.cnf部分发行版会放这里3编译期指定的SYSCONFDIR/my.cnf由安装方式决定不固定4$MYSQL_HOME/my.cnf环境变量指向的目录多实例场景常用5--defaults-extra-file指定的文件命令行显式指定必须放在第一个参数位6~/.my.cnf当前执行用户的家目录只影响该用户7~/.mylogin.cnf登录路径文件由mysql_config_editor生成这里有两个关键理解点。第一“对每一级只读第一个存在的文件”意味着/etc/my.cnf和/etc/mysql/my.cnf不会叠加生效如果两者都存在读的是前者后者被完全跳过。所以别指望把参数分散写在两个文件里那是最容易出问题的做法。第二同一个参数在多个层级里都出现时后面的覆盖前面的所以~/.my.cnf里的设置会盖掉全局配置。配置文件内部还有一个维度是参数组。文件里用方括号分段[mysqld]段只对服务端生效[client]段对客户端工具生效[mysql]只对mysql命令行工具生效。把这几个搞混是很常见的错误来源比如把character-set-server写到[client]段里那它永远不会影响服务端反过来把default-character-set写到[mysqld]段里服务端会直接报未知参数。还有两个指令值得记住!include用来包含单个文件!includedir用来包含一个目录下的所有.cnf文件。很多发行版的/etc/my.cnf内容极简只有几行!includedir实际参数散落在/etc/mysql/conf.d/或者/etc/my.cnf.d/里。遇到这种布局光看主配置文件会觉得“什么都没配”必须顺着包含关系一层层看下去。2.2mysqld-auto.cnf这个“后来者”8.0 引入了一个会打乱很多人认知的文件mysqld-auto.cnf它在数据目录下格式是 JSON。这个文件的作用是记录通过SET PERSIST或者SET PERSIST_ONLY持久化的动态参数。它的读取时机在所有传统配置文件之后所以它的优先级最高能覆盖你在my.cnf里写的同项设置。这个机制带来的实际影响是你在配置里把某个参数从 A 改成 B重启后发现值还是 A很可能就是因为之前有人执行过SET PERSIST把 A 写进了mysqld-auto.cnf。想验证的话SHOW VARIABLES LIKE persisted_globals_load;看这个开关是否打开再查一下performance_schema.persisted_variables表就能看到所有被持久化的参数。需要清理的话用RESET PERSIST 参数名或者RESET PERSIST全清不建议直接手改那个 JSON 文件。注意这个机制有它的价值比如临时把某个参数调到更适合当前负载的值用SET PERSIST既能立刻生效又能扛住重启比“改文件 重启”效率高得多。但它的副作用是可追溯性变差配置的真相被拆散在文件系统和数据目录两处。团队协作时我建议约定一条规则结构性配置写文件运行期调优用SET PERSIST并且每次持久化操作都在变更记录里留一笔。2.3 Windows 环境的差异Windows 上的查找顺序和 Linux 完全不是一回事主要候选是这几个%WINDIR%\my.ini和%WINDIR%\my.cnf然后是安装目录下的my.ini和my.cnf再往后是C:\ProgramData\MySQL\MySQL Server 版本号\my.ini这一类由安装器生成的路径。最后一类路径是 MSI 安装器默认使用的名字里带版本号升级版本时路径会跟着变这一点经常让人困惑。Windows 上还有一个额外因素是注册表。用 MSI 安装的实例服务注册信息里记录了启动参数服务启动时实际读取的文件可能和你想的不是同一个。排查方式和 Linux 类似但不完全一样查服务属性里可执行文件路径那一栏看有没有--defaults-file再确认路径指向哪个文件。实用的一点是Windows 上配置文件的编码有讲究用不支持 BOM 的编辑器保存没问题但有些编辑器会写入 UTF-8 BOM 头导致服务端把第一行当成乱码参数启动时直接报语法错误。我遇到过好几次第一次遇到时确实卡了很久。2.4 三条命令验证别靠猜上面说的这些顺序规则记不住没关系但一定要会用命令验证。最直接的一条是mysqld --print-defaults它会打印出服务端实际读取的配置项列表你能直接从输出里看到哪些参数生效了。客户端工具同理用mysql --print-defaults看客户端读取了什么。第二条是mysqld --verbose --help的头部输出。这个命令前面几行会打印出配置文件的搜索顺序以及实际找到的文件路径格式是“Default options are read from the following files in the given order”后面跟一串路径。这行输出基本就是最终答案比自己推理快得多。注意这条命令会输出巨量内容配合head或者grep用。第三条是 8.0.16 之后提供的配置校验选项mysqld --defaults-file/路径/my.cnf --validate-config。它只做语法和参数名校验不真正启动服务返回码为 0 就说明配置能过。这个命令在变更前先跑一遍能挡掉大部分“改完起不来”的事故。老版本没有这个选项退而求其次的做法是用--defaults-file加上--help试跑参数名写错时同样会报错。3. 关键参数的取舍每个数字都要说得清来路配置文件的写法可以很随意但里面每个数字背后都应该有理由。我不太认同“抄一份别人的配置直接用”这种做法因为机器规格、负载类型、数据量都不一样抄来的参数大概率不合适而且出了问题你不知道该调哪个。这一节把几类核心参数的计算思路讲清楚方便你按自己的实际情况套。3.1 路径与连接类基础块别写错[mysqld] user mysql basedir /opt/mysql datadir /data/mysql/data tmpdir /data/mysql/tmp socket /data/mysql/run/mysql.sock port 3306 pid-file /data/mysql/run/mysql.pid log-error /data/mysql/log/error.log这一段是整个配置的基础看起来都是路径实际每一条都有讲究。user指定进程降权后使用的用户Linux 上几乎所有部署都要写。basedir和datadir分开写的好处是把程序和数据解耦升级时只替换basedir数据目录原地不动回滚也方便。这在实践中的价值很大尤其当版本升级遇到问题时你能快速退回旧版本而不影响数据。socket这一条值得单独说。Linux 上本机连接可以走 socket 而不走 TCP速度快也绕开了网络层。但 socket 文件路径如果在客户端和服务端之间不一致就会出现一个经典现象服务端明明在跑mysql -u root -p却提示连不上。原因通常是客户端读到了另一个路径。解决方式是在[client]段里也写明同一个 socket 路径或者干脆连的时候用-S显式指定。多实例部署时这个坑出现频率极高因为每个实例的 socket 必须不同。tmpdir前面提过一次这里补充一点这个目录要允许mysqld进程读写和创建子目录权限不足时症状是查询报“无法创建临时文件”但整个实例的其他功能全都正常很容易被误判为业务代码问题。3.2 内存参数的计算过程含实例内存类参数是最容易拍脑袋写的一类也是影响最大的一类。我给一个可复现的计算流程用一台 32 GB 内存、仅运行数据库的机器做例子。第一步定innodb_buffer_pool_size。这是 InnoDB 缓存数据和索引的内存区直接决定读操作的命中率。专用机器上一般取物理内存的 60% 到 75%。32 GB 取 70%也就是 22 GB 左右写innodb_buffer_pool_size 22G。如果这台机器上还跑着其他占内存的服务比例就要往下压压到 50% 甚至 40%。第二步定innodb_buffer_pool_instances。这个参数的作用是把缓冲池分成多份减少并发访问时的锁竞争前提是总量够大。规则是每个实例至少 1 GB总量小于 1 GB 时该参数无效。22 GB 分成 8 份每份 2.75 GB写innodb_buffer_pool_instances 8。分成太细反而增加管理开销我一般控制在 4 到 16 之间。第三步估算连接内存。这一块经常被低估因为它是按连接乘以倍数的。相关参数包括sort_buffer_size、join_buffer_size、read_buffer_size、binlog_cache_size等每个连接在执行特定操作时会申请对应大小的内存。假设max_connections 500sort_buffer_size 2M最坏情况下 500 个连接同时做排序就是 1 GB。实际不会所有连接同时达到峰值但规划时要留出余量。我的做法是这类 per-connection 参数保持默认或者小幅上调sort_buffer_size不要超过 4 MBjoin_buffer_size不要超过 8 MB把优化的重点放在 SQL 和索引上而不是靠加大缓冲去“缓解”慢查询。第四步核对总量。22 GB 缓冲池 1 GB 连接内存 约 1 GB 给 redo 和其他结构 操作系统自身占用32 GB 的机器还剩不少余量。如果算下来超过物理内存说明某个参数定大了必须先改否则触发交换分区性能会断崖式下跌。innodb_buffer_pool_size 22G innodb_buffer_pool_instances 8 max_connections 500 sort_buffer_size 2M join_buffer_size 4M提示缓冲池的调整在 8.0 支持在线动态修改SET GLOBAL innodb_buffer_pool_size 24G就能生效不需要重启。但缩小时会有一段等待期因为要等所有页面被清理出来业务低峰期操作更稳妥。另外记得看一眼Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads两个状态值前者是逻辑读总次数后者是真正落到磁盘的物理读次数两者比值能反映命中率长期低于 99% 说明缓冲池偏小或者存在大量全表扫描。3.3 redo、binlog 与慢日志redo 日志相关参数在不同版本间的差异比较大这一点必须说清楚否则照抄旧文章会踩坑。8.0.30 之前redo 容量等于innodb_log_file_size乘以innodb_log_files_in_group常见配置是单文件 1 GB、两个文件共 2 GB。8.0.30 之后引入了innodb_redo_log_capacity用一个参数直接控制总容量默认 100 MB数据目录下的#innodb_redo里会维护 32 个文件。如果你在 8.0.30 之后的版本里继续写innodb_log_file_size它会被当作兼容参数处理但实际生效的是新参数容易造成“改了没反应”的困惑。容量怎么定看写入负载。redo 的作用是缓冲写操作容量大一些能减少检查点刷盘的频率对写入密集的负载有好处。经验值是总容量设在 1 GB 到 4 GB 之间写入特别密集可以到 8 GB。但要注意redo 容量越大异常恢复时需要的重放时间越长。我在一个写入量很大的场景里把容量从 1 GB 提到 4 GB写入吞吐有比较明显的改善代价是极端情况下的恢复时间变长这是需要权衡的。# 8.0.30 及以上 innodb_redo_log_capacity 4G # 8.0.30 之前 innodb_log_file_size 1G innodb_log_files_in_group 2binlog 这边sync_binlog是最需要想清楚的一个。设为 1 表示每次事务提交都刷盘最安全性能代价也最大设为 0 交给操作系统决定刷盘时机性能最好但异常断电可能丢日志。主库上我一般坚持设为 1从库和有完整备份兜底的场景可以适当放宽。max_binlog_size默认 1 GB这个值只是“单个文件尝试不超过这个大小”一个超大事务仍可能写出几 GB 的文件所以别指望靠它限制单个文件体积真正管用的是控制事务粒度。保留时长用binlog_expire_logs_seconds控制8.0 用秒为单位比 5.7 的expire_logs_days更灵活一般设 7 天到 14 天具体看备份策略能不能覆盖到这个窗口。慢查询日志这块slow_query_log、slow_query_log_file、long_query_time三个是基本盘。long_query_time支持小数别只写整数 1很多问题查询恰好落在 0.5 到 1 秒之间写 1 会漏掉。我通常从 0.5 起步稳定之后按实际情况调整。8.0.14 之后有log_slow_extra打开后慢日志里会记录更详细的执行信息包括扫描行数、临时表情况等代价是日志变大排查阶段建议打开长期开着要注意日志轮转。参数建议值主要考虑sync_binlog1主库必须保证不丢事务max_binlog_size512M 到 1G便于单个文件传输与处理binlog_expire_logs_seconds6048007 天与备份周期匹配long_query_time0.5用小数能覆盖更多问题查询log_slow_extraON排查期开启长期开启注意轮转innodb_flush_log_at_trx_commit1与sync_binlog配合保证持久性3.4 字符集、sql_mode 与表名大小写字符集在 8.0 上默认已经是utf8mb4配utf8mb4_0900_ai_ci大多数场景不需要改。但如果实例是从 5.7 升级上来的或者需要和下游系统保持排序规则一致就显式写清楚character_set_server utf8mb4、collation_server utf8mb4_0900_ai_ci。写到[mysqld]段里别写到[client]段。sql_mode建议保留严格模式的组合把STRICT_TRANS_TABLES、ONLY_FULL_GROUP_BY这些留着。理由很实在严格模式下字段超长、类型不匹配、插入 NULL 到非空列这类问题会直接报错让你在开发阶段就发现问题关掉严格模式之后数据会被静默截断或改写等到业务发现数据不对追溯成本高得多。ONLY_FULL_GROUP_BY会让一些写法不规范的GROUP BY查询报错短期内可能带来改造工作量但长期看是必要的约束。lower_case_table_names这个参数要单独强调它只能在初始化实例时设定初始化完成之后不能改。Linux 默认是 0区分大小写Windows 默认是 1不区分。跨平台迁移时如果没对齐这个值就会出现表找不到的问题。规划阶段就要确定下来别等数据都导进去了才发现两边不一致那时候只能重新初始化再导一遍。4. 一次完整的落地自定义目录初始化与数据搬迁前面讲的都是认知层面的东西这一节走一遍完整流程把目录规划和配置落地串起来。场景设定为在一台新机器上用自定义目录部署一个 8.0 实例然后把旧实例的数据迁过来。4.1 先做规划表动手之前先把目录规划写下来这一步花十分钟能省后面几小时的返工。原则是程序和配置一组、数据和日志一组、临时文件和备份一组尽量不要全塞在一个分区里。用途路径示例建议权限说明程序目录/opt/mysql755属主root升级时整目录替换配置文件/etc/my-custom.cnf644属主root别设成全局可写数据目录/data/mysql/data750属主mysql独占分区日志目录/data/mysql/log750属主mysql错误日志、慢日志临时目录/data/mysql/tmp750属主mysql容量要留够运行文件/data/mysql/run750属主mysqlsocket、pid备份目录/backup/mysql750属主mysql最好在另一块盘配置文件权限那条很重要。my.cnf如果被设成全局可写比如chmod 777mysqld会直接忽略它并在错误日志里留下一条警告。这个设计是为了防止任意用户篡改数据库配置但表现出的症状就是“配置不生效”而且警告埋在一堆日志里很容易被忽略。所以配置文件保持644、属主root是最省心的。4.2 初始化与配置文件落地先建目录、改属主然后写配置文件再初始化。顺序不能反因为初始化时就要用到配置文件里的路径。# 建目录 mkdir -p /data/mysql/{data,log,tmp,run} chown -R mysql:mysql /data/mysql chmod 750 /data/mysql/data /data/mysql/log /data/mysql/tmp /data/mysql/run # 写配置文件 cat /etc/my-custom.cnf EOF [mysqld] user mysql basedir /opt/mysql datadir /data/mysql/data tmpdir /data/mysql/tmp socket /data/mysql/run/mysql.sock pid-file /data/mysql/run/mysql.pid log-error /data/mysql/log/error.log port 3306 character_set_server utf8mb4 collation_server utf8mb4_0900_ai_ci innodb_buffer_pool_size 22G innodb_buffer_pool_instances 8 innodb_redo_log_capacity 4G max_connections 500 slow_query_log 1 slow_query_log_file /data/mysql/log/slow.log long_query_time 0.5 binlog_expire_logs_seconds 604800 lower_case_table_names 1 [client] socket /data/mysql/run/mysql.sock EOF chmod 644 /etc/my-custom.cnf初始化这一步有几个必须注意的点。--defaults-file必须是命令行的第一个参数位置放错了会被忽略。--initialize会生成一个临时的 root 密码并写入错误日志初始化完成后要去日志里找。整个过程不要加--initialize-insecure那个选项会生成空密码的 root虽然方便但线上环境不合适。/opt/mysql/bin/mysqld --defaults-file/etc/my-custom.cnf --initialize --usermysql # 初始化完成后找临时密码 grep -i temporary password /data/mysql/log/error.log如果你不确定配置写得对不对在初始化之前先跑一次校验能省掉一次失败重来的时间/opt/mysql/bin/mysqld --defaults-file/etc/my-custom.cnf --validate-config启动方式上验证阶段可以直接用命令行拉起观察输出更直观稳定之后交给服务管理器托管。/opt/mysql/bin/mysqld --defaults-file/etc/my-custom.cnf --daemonize4.3 搬迁数据目录的完整流程旧实例的数据要迁过来这里给的是整目录搬迁的做法适用于数据量不算特别大、可以接受停机窗口的场景。数据量大或者停机窗口极短的场景应该用备份恢复或者复制方案那是另一个话题。第一步旧实例上做一次干净关库。不要直接 kill 进程mysqladmin shutdown或者服务管理器停服务都可以。关库过程中 InnoDB 会做一次检查点把脏页刷下去这能让搬迁后的启动快很多也避免了异常停机带来的恢复过程。第二步确认旧实例的目录布局和新实例规划一致主要是datadir里的内容整体搬过去。用rsync而不是cp因为rsync支持断点续传和增量几百 GB 的中断重来会很难受。rsync -av --progress /旧路径/data/ /data/mysql/data/第三步处理权限。rsync -a会保留属主和权限但跨机器、跨用户 ID 映射时可能对不上统一改成mysql:mysql更保险。chown -R mysql:mysql /data/mysql/data第四步检查auto.cnf。如果新实例已经初始化过它的auto.cnf是自己的 UUID旧数据目录里带着旧的 UUID。整目录覆盖时需要决定保留哪一个。单实例场景下关系不大但如果有复制关系必须让每个实例的 UUID 唯一否则从库连上来会报错。最省事的做法是直接把旧数据目录里的auto.cnf删掉启动时它会重新生成一个新的。第五步处理可能存在的配置冲突。旧实例上如果有SET PERSIST写下的参数那些值会跟着数据目录一起搬过来并且优先级高于你的新配置文件。搬迁完成后务必查一下performance_schema.persisted_variables把不需要的持久化参数清掉。第六步启动并验证。启动后先看错误日志有没有异常再连上去做基础检查。4.4 启动后校验清单搬迁或者新部署完成后我有一套固定的检查项目一项项过一遍比凭感觉判断“看起来正常”靠谱。-- 版本和路径 SELECT VERSION(), basedir, datadir, tmpdir, socket; -- 参数是否按预期生效 SHOW VARIABLES LIKE innodb_buffer_pool_size; SHOW VARIABLES LIKE character_set_server; SHOW VARIABLES LIKE lower_case_table_names; SHOW VARIABLES LIKE max_connections; -- 持久化参数确认 SELECT * FROM performance_schema.persisted_variables; -- 存储引擎状态 SHOW ENGINE INNODB STATUS\G -- 库表数量是否与旧实例一致 SELECT COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN (mysql,sys,performance_schema,information_schema);最后一项尤其重要。整目录搬迁之后库和表的数量必须与旧实例完全一致逐个COUNT对比一下花不了多少时间但能第一时间发现搬迁不完整的问题。另外建议抽查两三个大表做一次CHECKSUM TABLE确认数据页完整。我见过迁移过程中磁盘空间不足导致文件被截断的情况表结构在、数据缺了一部分如果不做校验可能要等业务查询到具体某一行才发现。5. 常见问题与排查实录这一节把实际遇到过的高频问题整理出来按现象归类配上排查路径和解决方式。这类经验通常不会写在官方文档里但踩过一次之后印象会非常深刻。5.1 配置不生效的六种情形第一个情形改的文件没被读到。判断方法是mysqld --print-defaults看实际加载的列表或者直接看--verbose --help输出的搜索路径。第二个情形读到了但被后面的文件覆盖。典型是/etc/my.cnf里设了值~/.my.cnf或mysqld-auto.cnf里又设了不同的值。按优先级顺序后面的赢。第三个情形参数写在了错误的段里。写在[client]段的character-set-server永远不会影响服务端写在[mysqld_safe]段的部分参数也不会传递给mysqld。第四个情形参数名拼写错误或者版本不支持。比如在 5.7 上写innodb_redo_log_capacity这个参数根本不存在服务端启动时会报未知参数错误但如果是通过某些面板启动的错误可能被吞掉了。用--validate-config能提前发现。第五个情形参数属于只读变量改了也不会变。lower_case_table_names就是典型只能在初始化的那一刻决定。第六个情形配置文件权限过宽被忽略。前面说过了全局可写的配置文件会被跳过日志里有警告。现象最可能原因快速验证改完重启无变化加载的不是这个文件mysqld --print-defaults部分参数生效部分不生效多文件覆盖查mysqld-auto.cnf与家目录配置启动直接报错参数名错误或值非法--validate-config客户端连不上socket 路径不一致比对[client]段与-S参数服务端变量全是默认值配置被忽略权限或路径看错误日志开头的警告5.2 启动失败的排查顺序启动失败时不要盲改配置按这个顺序走大多数问题能在三步内定位。第一步看错误日志的最后几十行。日志路径由log-error决定如果启动参数里没写多数情况下落在datadir下的.err文件里。日志里最后一条错误通常就是根因前面那些往往只是连带现象。第二步看磁盘空间。df -h看一眼数据目录所在分区。磁盘满的表现很迷惑服务能起来一小会儿然后挂掉或者起来之后所有写操作都报错。这种情况下配置怎么改都没用。第三步看权限。用sudo -u mysql ls -ld沿数据目录逐层检查特别注意父级目录和挂载点。第四步看文件是否存在。ibdata1、undo_001、#innodb_redo这些关键文件缺失时服务端会直接拒绝启动并给出明确提示不要试图手工创建这些文件重建它们是不可能的只能从备份恢复。第五步看端口和 socket 冲突。同一台机器上起两个实例用了同一个端口或者上一个实例的 socket 文件残留都会导致启动失败。ss -lntp | grep 3306能直接看到端口占用情况。第六步看 redo 相关参数的改动。如果最近调过 redo 容量并直接重启启动过程中会有明显的重放阶段数据量大时可能长达几十分钟。这时候服务看起来像“卡住了”其实是在干活。观察错误日志有没有持续输出进度别急着 kill 进程强行中断可能导致更麻烦的状态。注意曾经遇到过一次很典型的误判错误日志最后一行是“无法创建 PID 文件”很多人会去查pid-file路径。但真正的原因是pid-file所在的目录不存在mysqld不会自动创建这个目录。这类“目录不存在”引发的问题还有一种表现错误日志本身写不出来因为log-error指定的目录也不存在此时错误只能输出到标准错误通过服务管理器启动的话就完全看不到了。所以我在自定义部署时第一步永远是mkdir -p把所有目录建好。5.3 实操中总结的几条经验关于配置文件组织方式我个人的做法是单一主文件加少量附。不要搞成七八个碎片文件互相!include出问题时排查成本太高。如果确实需要按用途拆分比如把内存参数、日志参数分开那就在文件名上明确体现并且确保拆分之后的加载顺序是可控的。关于参数变更流程我现在固定执行三步改文件之前先SHOW VARIABLES记录当前值改完之后先--validate-config确认无误再重启重启后立刻再SHOW VARIABLES对比。这个流程看着啰嗦但能避免绝大多数“改了不知道生效没生效”的困惑。对于支持动态修改的参数优先用SET GLOBAL验证效果确认合适之后再写进配置文件固化下来这样能避免一次不必要的重启。关于目录规划一个长期有效的建议是把数据目录、日志目录、备份目录分到不同的物理设备上。这样做不只是为了性能更重要的是故障隔离。日志写爆磁盘不会影响数据文件写入备份写满也不会拖垮实例。如果硬件条件有限做不到那至少保证数据目录独享一个分区别和操作系统共用。最后分享一个排查问题时很实用的小技巧当你怀疑某个参数没生效、又找不到原因时用mysqld --defaults-file/路径/my.cnf --verbose --help把输出重定向到文件然后grep你关心的参数名。这个输出里包含所有参数的最终生效值和来源比一个个去猜配置文件有没有被读到要快得多。我用这个方法定位过好几次“配置被上层目录的某个文件覆盖”的问题那些文件藏在!includedir指向的目录里手动翻很难翻全。还有一点是关于备份的目录结构和配置文件本身也应该纳入备份范围。数据备份做得再勤恢复时没有对应的配置文件和目录结构一样要重新摸索一遍。我习惯在每次配置变更后把配置文件单独存一份到备份目录命名带上时间和变更摘要成本几乎为零恢复时的价值却很高。