MySQL 装完之后很多人第一反应就是敲mysql -uroot -p进去写 SQL目录长什么样、配置文件在哪、参数从哪来的一律不管。平时没出事倒也无所谓可一旦碰上磁盘告警、实例起不来、改了参数重启不生效、主从数据对不上这类问题就得回到这些地基上找答案。我见过不少线上故障最后追下去都是 datadir 挂载点被新加的分区覆盖了、配置文件写在了低优先级的路径里、或者把 redo log 当成可随手删除的临时文件。这篇就围绕 MySQL 的目录结构与配置文件展开把每个文件放在那里的理由、每个参数为什么要这样算讲清楚。不管你是刚接手一套实例的运维还是自己装了一套开发库的工程师或者正准备做一次实例迁移、备份策略设计下面这些内容都能直接拿去用。前 100 字先把关键词摆出来MySQL 目录结构、数据目录 datadir、配置文件 my.cnf、参数作用域、日志文件这几样是本文的主线。1. 目录结构整体设计为什么 MySQL 要把文件拆得这么散1.1 安装目录与数据目录的职责划分MySQL 把程序和数据分得很开安装目录basedir放的是二进制、库文件、头文件、手册数据目录datadir放的是用户数据、日志、表空间、套接字。这种拆分不是洁癖而是为了两件事一是升级时可以直接替换 basedir 而完全不动 datadir二是让 datadir 能单独挂一块大容量盘、做独立的快照和备份策略。你在基于通用二进制安装包部署之后把安装目录里所有东西删掉理论上都不影响已经启动的 mysqld 继续跑因为它运行时依赖的是已经映射进内存的二进制和打开的句柄反过来 datadir 一旦丢失basedir 再完整也只是一堆用不上的程序。basedir 下面通常有这些子目录bin放 mysqld、mysql、mysqldump、mysqladmin 等可执行文件lib放插件plugin目录plugin_dir参数默认指向这里include是给 C API 开发用的头文件share放字符集、错误消息模板errmsg.sys、时区定义、SQL 初始化脚本support-files里是几个现成的配置模板和启动脚本data在某些包结构里默认被当作 datadir 使用。真正需要你关心的只有 bin、lib/plugin 和 share 三处其余删掉基本不影响运行。datadir 的组织逻辑则以库为单位每个数据库对应一个同名目录目录里是该库的表文件。表名就是文件名所以文件名和库名、表名受同一个文件系统大小写规则和字符长度规则约束。这里有个老生常谈但每年都有人踩的坑如果在大小写敏感的文件系统上建了Order表之后把数据目录搬到大小写不敏感的文件系统上两个表order和Order就会撞名实例直接起不来或者表打不开。1.2 不同部署方式下的默认路径差异路径这件事源码编译、通用二进制包、系统包管理器安装三者的默认值完全不同。源码和通用包默认 basedir 是解压路径datadir 是 basedir 下的data系统包管理器装出来的通常 basedir 是/usrdatadir 是/var/lib/mysql配置文件落在/etc/my.cnf或/etc/mysql/my.cnf错误日志走/var/log/mysqld.log或 syslog。来源不同的实例你按别人的教程去改某个路径很可能改的根本不是这个实例在用的那个文件。想一次性看清当前实例的真实情况别去猜直接问实例自己。下面这条 SQL 比翻任何文档都准确SELECT basedir AS basedir, datadir AS datadir, plugin_dir AS plugin_dir, socket AS socket, pid_file AS pid_file, log_error AS log_error, innodb_data_home_dir AS data_home, innodb_log_group_home_dir AS redo_home, log_bin_basename AS binlog_base;这几个变量分别回答了程序在哪数据在哪插件在哪通讯文件在哪进程号写在哪错误日志在哪InnoDB 系统表空间在哪redo 在哪binlog 前缀是什么。做迁移、做备份、写监控脚本之前先把这一屏结果截图存下来后面所有操作都以它为准。提示socket在 Windows 上通常是空值Windows 实例用命名管道或 TCP 端口通讯不要拿 Linux 的经验硬套。1.3 一套实例的完整目录清单长什么样把上面这些拼起来一个典型实例的文件分布大致是这样路径或文件归属作用能否删除basedir/bin安装目录可执行程序停库后可替换升级basedir/lib/plugin安装目录插件动态库不用的插件可删谨慎basedir/share安装目录字符集、错误消息、时区不能删datadir/数据目录所有库表与日志绝对不能删datadir/ibdata1数据目录InnoDB 系统表空间不能删datadir/mysql.ibd数据目录8.0 数据字典表空间不能删datadir/#innodb_redo数据目录8.0.30 的 redo 日志不能删datadir/*.ibd数据目录用户表独立表空间不能删datadir/mysql-bin.000001数据目录二进制日志按保留策略清理datadir/auto.cnf数据目录实例 UUID不要手改datadir/mysqld.pid数据目录进程号重启后覆盖datadir/mysql.sock数据目录本地套接字重启后重建/etc/my.cnf配置主配置文件修改前备份这张表看着平淡但它解决了一个很实际的问题当告警说数据盘快满了你能立刻判断是业务数据涨了、binlog 没清、还是临时表空间在疯长。三个方向的处置手段完全不同判断依据就藏在这张表里。2. 数据目录逐项拆解每个文件都不是随便放的2.1 系统表空间、独立表空间与临时表空间ibdata1是 InnoDB 的系统表空间文件初始 12MBinnodb_data_file_path控制它是否自动扩展以及扩展上限。它里面装着回滚段元信息、变更缓冲区change buffer、双写缓冲的一部分、以及早期版本里所有表的索引和数据。从 5.6 默认开启innodb_file_per_table之后用户表的数据和索引搬到了各自的.ibd文件里ibdata1 的膨胀压力小了很多但它仍然不会缩只会涨。这也是为什么很多人发现表删了、磁盘没释放——删掉的表空间文件确实被删了但 ibdata1 里那些不再复用的区段回不去。独立表空间.ibd的好处很直接单表可以单独备份transportable tablespace、单表可以单独回收磁盘、单表损坏的影响面可控。代价是文件句柄数量随表数量线性增长几万张表的实例要留意open_files_limit。另外.ibd内部被切成 16KB 的页删除大量数据只会在文件内部留下空洞磁盘空间不会自动归还想真正瘦身得走OPTIMIZE TABLE或者在线重建这中间需要额外的磁盘空间和主从延迟余量。临时表空间分两种会话级临时表空间#innodb_temp目录下的一组文件和全局临时表空间ibtmp1。排序、临时结果集、内部临时表都往这儿写。ibtmp1在实例重启时会重建所以它的大小异常通常意味着某个查询的排序量失控配合慢查询日志和SHOW ENGINE INNODB STATUS就能定位到具体语句而不是去调小临时表空间参数。把临时表空间调到内存盘上是个常见优化但要注意崩溃后临时数据不可恢复只对纯临时数据成立。undo_001、undo_002这类文件是 8.0 独有的独立 undo 表空间5.7 的 undo 还挤在 ibdata1 里。8.0 把 undo 独立出来是为了能在线收缩 undo 空间、也是为了让 undo 的 IO 更可控。长事务会撑大 undo实例上出现磁盘缓慢增长但 binlog 正常的情况先查information_schema.innodb_trx里有没有跑了几个小时的事务。2.2 redo 日志位置变了重要性没变8.0.30 之前的版本redo 是ib_logfile0、ib_logfile1两个固定文件名个数由innodb_log_files_in_group控制大小由innodb_log_file_size控制。8.0.30 之后改成#innodb_redo目录下若干个#ib_redo开头的文件由innodb_redo_log_capacity统一决定总量。这个变化让调大 redo从停机改文件变成了在线改参数但它带来的误解也不少有人看到目录里有一堆大小不一的文件以为是残留删掉几个然后实例直接崩了。redo 的作用是崩溃恢复。事务提交时先把变更写进 redoinnodb_flush_log_at_trx_commit1时还要 fsync脏页再异步刷盘。redo 容量不够时InnoDB 会被迫频繁推进 checkpoint、刷脏页表现出来就是写入抖动、innodb_log_waits增长。redo 太大则崩溃恢复时间变长。我一般的经验值是以写入压力中等偏上的业务为例redo 总量给到 1 到 4GB配合每秒写入量算一下能覆盖多久的峰值保证覆盖 15 分钟以上的写入量给 checkpoint 留出余量。redo 和 binlog 常被混淆。简单区分redo 是 InnoDB 存储引擎层的物理日志记录哪个页的哪个偏移改了什么服务于崩溃恢复binlog 是 Server 层的逻辑日志记录执行了什么语句或行变更服务于主从复制和时间点恢复。两者的写入时机通过两阶段提交协调这也是为什么sync_binlog和innodb_flush_log_at_trx_commit两个参数要一起看只调一个并不能决定整体持久性。2.3 二进制日志、中继日志与索引文件开启log_bin之后数据目录下会出现mysql-bin.000001这样的文件外加一个mysql-bin.index。索引文件是纯文本的清单列出当前有哪些 binlog 可用binlog 文件本身是二进制格式用mysqlbinlog解析。日常运维里binlog 是磁盘增长最快的东西一次大批量导入能产生几十 GB。控制它靠binlog_expire_logs_seconds8.0替代了 5.7 的expire_logs_days和max_binlog_size前者决定保留时长后者决定单文件大小上限注意单文件超过上限只在事务边界切分所以大事务会突破上限。中继日志relay-log只在从库出现是 IO 线程从主库拉下来、SQL 线程待回放的本地副本。relay_log_purge默认为 ONSQL 线程应用完就自动清理。relay_log_recovery建议设为 ON让从库重启后能自动丢弃未完成的中继日志重新拉取避免半截事务导致的复制中断。master.info和relay-log.info这两个文件在 5.6 之后已经被mysql.slave_master_info、mysql.slave_relay_log_info两张表取代配置文件里还能看到相关参数但别再去手工编辑这两个旧文件。还有一类容易被忽视的#sql-xxxx_xxxx.ibd这种临时文件。这是在线 DDL 过程中产生的中间表文件正常结束后自动消失。如果实例在 DDL 期间异常中断这类文件会留在 datadir 里占着空间。清不清要确认没有任何 DDL 在进行、实例状态干净之后才能动手否则可能把正在重建的表搞坏。我的做法是先记下文件名和时间戳观察几天确认不再变化再在低峰期清理。2.4 那些小文件UUID、PID、套接字与错误日志auto.cnf里存着server_uuid主从架构下这个值必须全局唯一。克隆虚拟机、复制数据目录做测试库时如果没有重新生成两套实例的 UUID 会撞车某些依赖 UUID 做标识的场景会出诡异问题。8.0 在数据目录初始化时会自动生成也可以用--initialize时指定的方式重新产生。改它的正确姿势是停库、删掉 auto.cnf、启动让实例重新生成同时确认主从关系不会因此错乱。mysqld.pid是进程号文件safe_mysqld和系统服务脚本靠它判断实例是否在运行。启动失败时提示server quit without updating PID file字面意思就是 mysqld 没起来pid 文件没被写。真正的错误原因一定在错误日志里这句话本身不包含任何诊断信息别在它上面浪费时间。套接字mysql.sock是本地连接的通道客户端连localhost时默认走它走 TCP 时才用127.0.0.1。这里有个经典的坑命令行能连、程序连不上或者反过来八成是localhost和127.0.0.1走了不同通道而账号的 host 授权也不一样。socket参数在配置里改过之后客户端配置段里的socket也要同步否则本地连接直接报找不到套接字文件。错误日志是最该先看、也最容易被忽略的文件。它记录启动过程、InnoDB 初始化、崩溃恢复、以及各类警告。判断一套实例健不健康翻最近几百行错误日志比看任何监控面板都直观。日志轮转记得做超大错误日志会影响写入而且出问题时用tail -f打开会非常慢。3. 配置文件加载顺序与写法详解3.1 优先级规则谁覆盖谁MySQL 的配置文件不是一个是一串按固定顺序读取后读的覆盖先读的。通用二进制包和系统包在不同平台上大致遵循这个顺序# 查看当前版本实际读取的文件顺序8.0 的写法 mysqld --verbose --help 2/dev/null | grep -A 20 Default options are read # 更直接的办法只打印将被采用的默认值 mysqld --print-defaults # 5.7 及更早版本 mysqld --verbose --help 2/dev/null | grep -A 1 Default options在 Linux 上典型顺序是/etc/my.cnf→/etc/mysql/my.cnf→ 编译时指定的SYSCONFDIR/my.cnf→$MYSQL_HOME/my.cnf→~/.my.cnf与~/.mylogin.cnf。最后两个是针对当前登录用户的优先级最高但只对同一个用户启动的客户端生效。~/.mylogin.cnf是加密文件由mysql_config_editor生成用来存登录凭据不要和~/.my.cnf混为一谈。这个顺序解释了两种常见的困惑。第一种我在/etc/my.cnf里改了参数重启没生效。原因通常是这个实例的启动脚本用--defaults-file显式指定了另一个配置文件此时其余所有路径上的配置文件都被忽略只看那一个。第二种命令行里能连服务脚本连不上。因为两者读取的配置文件集合不同套接字路径、端口可能就不一样。注意--defaults-file出现时只读它指定的那一个文件前面说的整套优先级直接失效。这是排查参数不生效的第一检查点。3.2 分段结构每个[方括号]服务的是谁配置文件用方括号分段每个段只对对应的程序生效。这个设计的意义在于一次配置、多方共享但也是参数写错位置的根源。[client] port 3306 socket /var/lib/mysql/mysql.sock default-character-set utf8mb4 [mysqld] user mysql basedir /usr/local/mysql datadir /var/lib/mysql socket /var/lib/mysql/mysql.sock pid-file /var/lib/mysql/mysqld.pid port 3306 log-error /var/log/mysql/error.log character-set-server utf8mb4 collation-server utf8mb4_0900_ai_ci max_connections 800 innodb_buffer_pool_size 40G innodb_redo_log_capacity 4G innodb_flush_log_at_trx_commit 1 sync_binlog 1 binlog_expire_logs_seconds 604800 slow_query_log ON long_query_time 1 log_error_verbosity 2 [mysqld_safe] log-error /var/log/mysql/error.log pid-file /var/lib/mysql/mysqld.pid [mysql] default-character-set utf8mb4 [mysqldump] max_allowed_packet 256M[client]段被所有客户端程序读取包括mysql、mysqldump、mysqladmin所以把 socket 和字符集放在这里最省事。[mysqld]是服务端段90% 的参数都写在这里。[mysqld_safe]是启动包装脚本自己的段日志路径和 pid 路径写在这里能让包装脚本在 mysqld 尚未启动时就找到日志。[mysql]、[mysqldump]是单个客户端段优先级高于[client]。一个高频错误是把服务端参数写进[client]段。比如把max_connections写在[client]下客户端不认识这个参数可能直接报 unknown variable 而不启动反过来把只对客户端有意义的default-character-set写进[mysqld]8.0 会提示变量不存在。参数到底属于哪一段用mysqld --verbose --help查里面列出的就是服务端可识别的全集。3.3 参数三级作用域与三种修改方式参数从作用域上分全局GLOBAL和会话SESSION两类而全局参数又按能否在线修改分成动态和静态。这三层叠加就有了三种修改方式选错了就会出现改了没生效或者要重启才生效的落差。修改方式命令生效范围是否持久化适用场景会话级SET SESSION x v当前连接否临时调大 sort_buffer 之类全局动态SET GLOBAL x v新连接否重启丢失应急调参、验证效果全局持久化SET PERSIST x v新连接是写入 mysqld-auto.cnf8.0 推荐方式配置文件编辑 my.cnf 后重启全实例是静态参数、长期配置SET PERSIST是 8.0 引入的它把值写进 datadir 下的mysqld-auto.cnf这个文件的优先级高于所有 my.cnf所以用SET PERSIST改过的参数你在 my.cnf 里再改是无效的只会看到配置里写的是 A实际值是 B。这个设计坑过不少人。检查办法是看performance_schema.persisted_variables表SELECT * FROM performance_schema.persisted_variables;发现某个参数被持久化过用RESET PERSIST 参数名清掉再改配置文件才有效。SET PERSIST_ONLY则只写文件不改变当前运行值适合给静态参数设置下次启动值。静态参数只能在配置文件里改改完重启。比如innodb_page_size、datadir、log_bin部分版本可动态开关。判断一个参数能不能在线改看SHOW VARIABLES输出没用要看对应版本的文档或者直接SET GLOBAL试一下报 is a read only variable 的就是静态的。4. 实操定位配置、调参与生效验证4.1 第一步永远是确认这个实例用的是哪份配置我接手一套陌生实例时动作顺序固定是这三步。第一步看进程命令行ps -ef | grep [m]ysqld输出里如果出现--defaults-file/xxx/my.cnf那就以它为准其他全部忽略。如果没有这个参数就说明走的是默认搜索路径用前面那条mysqld --verbose --help拿到的顺序去逐个确认文件是否存在以及最后生效的是哪个值。第二步确认当前运行值SHOW VARIABLES WHERE Variable_name IN ( datadir,basedir,innodb_buffer_pool_size, innodb_redo_log_capacity,max_connections, log_bin_basename,log_error,slow_query_log,long_query_time );第三步反查配置文件里是怎么写的grep -nE ^\s*(datadir|innodb_buffer_pool_size|max_connections) /etc/my.cnf三步对上才算搞清楚现状。任何一次调参之前不做这三步的后面大概率要花更多时间返工。4.2 计算两个最关键参数的取值内存类参数里innodb_buffer_pool_size是影响最大的一项。经验规则是给物理内存的 50% 到 75%剩余留给连接线程、临时表、排序缓冲、操作系统页缓存和别的小进程。以一台 64GB 内存、只跑 MySQL 的机器为例取 70% 是 44.8GB但要按 buffer pool 的 chunk 大小取整8.0 下innodb_buffer_pool_instances每个实例至少 1GB如果设成 8 个实例每个实例 5.5GB 左右总量取 40GB 或 44GB 都比 44.8GB 稳妥。设 75% 以上常见于专机专用且内存压力可控的场景但一旦堆到 80% 以上备份工具、批量导入、临时排序就可能触发 swap性能断崖式下降这个代价远大于多缓存几 GB 数据。innodb_redo_log_capacity8.0.30的算法更偏经验按峰值写入速率 × 覆盖时长估。假设峰值 TPS 2000、每事务平均 2KB 的 redo 产出每秒就是 4MB 左右希望覆盖 15 分钟就是 4MB × 900 ≈ 3.6GB取 4GB。低于 1GB 会显著增加 checkpoint 频率高于 16GB 则崩溃恢复时间拉长。虚拟机、云盘环境下还要考虑存储的写放大和突发配额redo 一次性 fsync 的量太大会被限速。max_connections不能光看应用连接池配置。每个连接本身有基础开销还要预留排序缓冲、连接缓冲等按需分配的内存。把max_connections× 单连接峰值内存 估出来和剩余内存比一比再决定要不要开thread_cache_size、要不要上连接池中间件。盲目调大连接数的结果通常是连接数上去了吞吐反而掉了。4.3 修改、验证、回滚的完整闭环参数修改我坚持一个闭环先在线验证、再落配置、最后重启复核。以调整慢查询阈值举例-- 1. 在线改观察效果不落盘 SET GLOBAL long_query_time 0.5; SHOW GLOBAL VARIABLES LIKE long_query_time; -- 2. 跑一段业务看慢查询数量是否可控 SELECT COUNT(*) FROM mysql.slow_log; -- 需先开启 log_outputTABLE确认阈值合适之后再写进配置文件[mysqld]段然后决定是否需要重启。long_query_time是动态参数SET GLOBAL对已建立的连接不生效会话级变量在连接建立时继承全局值所以要么重连要么对每个连接单独设置。这也是为什么改完动态参数后最好还是做一次滚动重启让所有连接都拿到新值。静态参数比如innodb_page_size就没有在线验证这回事只能停机改。改之前必须做三件事备份配置文件原件、确认新值的兼容性比如innodb_page_size只能在--initialize阶段设定后期改必须重建实例、准备好回滚脚本和回滚时间窗。我通常会把配置变更做在维护窗口里改完启动后立刻验证四件事错误日志无 ERROR、SHOW SLAVE STATUS复制正常、核心表能读能写、关键业务 SQL 的执行计划没有变化。5. 常见问题与排查技巧实录5.1 典型问题速查表现象大概率原因排查动作处置办法改了 my.cnf 重启不生效启动时用了--defaults-file指定别处ps -ef看命令行改对的那个文件改了配置文件实际值还是旧的参数被SET PERSIST固化查persisted_variablesRESET PERSIST 参数名启动报 server quit without updating PID端口占用、datadir 权限、配置文件语法错tail -100 错误日志按日志提示逐项排除数据盘满但表数据没涨binlog 未清理、ibtmp1 暴涨、错误日志过大du -sh datadir/*排序调保留策略、查长事务本地能连、远程连不上套接字与 TCP 通道混淆、账号 host 授权分别用-h127.0.0.1和-S sock试统一连接方式补授权从库复制中断大事务、唯一键冲突、中继日志损坏SHOW SLAVE STATUS看 Last_Error跳过或重做开启relay_log_recovery表删了磁盘不释放ibdata1 不收缩、ibd 内部留空洞对比文件大小与逻辑数据量重建表或迁移表空间字符集乱码服务端、客户端、连接三层字符集不一致查character_set_%三组变量统一 utf8mb4改连接串这张表里的每一行我都在真实环境里遇到过至少一次其中参数被 SET PERSIST 固化和启动脚本用了 defaults-file这两条占了参数不生效问题的绝大多数。排查时先按这两条排除能省掉很多翻文档的时间。5.2 几条用血换来的避坑经验第一个别在生产机上直接编辑配置文件然后重启验证。正确做法是先复制一份到临时路径用mysqld --defaults-file/tmp/test.cnf --validate-config8.0 支持做语法校验通过了再替换。配置文件里一个多余的空格、一个中文全角符号、一个不认识的参数名都能让实例起不来而实例起不来的每一分钟都是实打实的损失。第二个datadir 的属主和权限要锁死。chown -R mysql:mysql datadir之后权限建议 750配置文件和 SSL 证书 640。别图省事给 777MySQL 遇到权限过宽的配置文件会直接警告甚至拒绝启动。另外注意 datadir 的父目录权限也要对否则 mysqld 以 mysql 用户身份无法穿透到子目录。第三个日志目录和 datadir 分开放。把错误日志、慢日志放在独立分区好处是日志写爆了不至于把数据盘撑满导致实例只读。binlog 则建议留在 datadir 同一块盘上因为 binlog 和数据的一致性在崩溃恢复时有关联分盘会引入额外的复杂度除非你有明确的性能隔离需求。第四个迁移实例时datadir 的复制必须在停机或一致性快照下进行。直接cp -r一个正在运行的 datadir拷出来的大概率是坏的因为 InnoDB 的页和 redo 在拷贝过程中一直在变。用文件系统快照、xtrabackup这类物理备份工具或者干脆mysqldump逻辑导出。第五个#innodb_redo目录里的文件、ibtmp1、#innodb_temp下的文件都不要手工删。前者删了直接丢数据后两者删了虽然重启会重建但如果在运行中删正在使用它们的会话会报错线上表现为一堆莫名其妙的临时表错误。要清就停库清或者用对应的参数控制。我自己在实际操作中的体会是MySQL 的目录结构和配置文件这套东西平时看着像背景噪音真正出问题的时候它就是唯一的线索来源。养成两个习惯收益很大一是每接一套实例先把datadir、basedir、实际生效的配置文件路径、日志路径这四项记进运维文档二是任何参数变更都走在线验证 → 落配置文件 → 重启复核 → 记录变更这个流程。前者能在故障时省掉十分钟的摸索后者能避免配置文件和运行值长期不一致这种隐形隐患。这套东西没什么高深技巧靠的就是把每个文件的来龙去脉捋清楚然后不动不该动的东西。