MySQL启动时仅加载第一个存在的my.cnf文件，顺序为/etc/my.cnf→/etc/mysql/my.cnf→$MYSQL_HOME/my.cnf→~/.my.cnf；后续文件被忽略，修改错误路径或权限不当（如world-writable）会导致配置不生效。
配置文件路径不对或没被加载
MySQL启动时会按固定顺序查找配置文件，不是所有my.cnf都会被读取。常见路径有/etc/my.cnf、/etc/mysql/my.cnf、$MYSQL_HOME/my.cnf、~/.my.cnf，但只有第一个存在的才会被加载（后续的会被忽略）。如果你改的是/home/user/my.cnf，而MySQL实际加载的是/etc/my.cnf，那修改就完全无效。
验证方法：运行mysqld --verbose --help | grep "Default options"，它会明确告诉你“Default options are read from”哪几个路径，按顺序排，只认第一个。
容易踩的坑：
- 编辑了错误路径的文件，比如在
/usr/etc/my.cnf里改，但该路径根本不在加载列表中 - 多个配置文件共存，比如
/etc/my.cnf和/etc/mysql/my.cnf都存在，MySQL只读前者，后者里的修改全被无视 - 用
mysql --defaults-file=...临时指定配置时，服务脚本（如systemd）仍走默认路径，导致“手动能启，systemctl启不了”
配置语法或参数本身不合法
MySQL对配置项非常敏感：拼写错误、单位写错、废弃参数、大小写混用，都可能导致启动直接失败，且错误日志里往往只报“unknown variable”或“option not recognized”，不指明第几行。
典型问题包括：
-
innodb_buffer_pool_size = 2G正确，但写成2GB或2g会被忽略（8.0+严格区分大小写，G必须大写） - MySQL 8.0+已移除
query_cache_size，保留它会报错退出 - 把
max_connections写成max_connection（少个s），参数名不存在，直接拒绝启动 - 在
[client]段里写了datadir，该参数只在[mysqld]段有效，放错位置也会报错
建议先用mysqld --defaults-file=/etc/my.cnf --validate-config校验（5.7.20+/8.0.14+支持），比反复重启快得多。
文件权限或路径不可访问
MySQL启动时会主动拒绝加载权限过宽的配置文件，典型错误是：World-writable config file '/etc/my.cnf' is ignored。只要my.cnf权限是666、777甚至664（组可写），MySQL就会跳过它，转而用内置默认值——这会导致datadir、log-error等关键路径失效，进而找不到数据目录或写不了日志，最终启动失败。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
其他路径类问题：
-
datadir = /data/mysql，但该目录不存在，或MySQL用户（如mysql）无读写权限 -
socket = /var/run/mysqld/mysqld.sock，但/var/run/mysqld/目录不存在，且MySQL无权创建 -
log-error = /var/log/mysql/error.log，但/var/log/mysql/目录属主不是mysql，或磁盘已满
修复前先确认：用ls -l /etc/my.cnf看权限（应为644），再用sudo -u mysql ls -ld /data/mysql /var/log/mysql确认目录可访问。
binlog或InnoDB相关路径异常
这类问题不报语法错，但一启动就卡住或秒退，日志里常出现File './mysql-bin.000001' not found或Failed to open log (errno 13)。
原因很具体：
- 手动删了
mysql-bin.*文件，但mysql-bin.index还记录着已删除的文件名，MySQL启动时按索引去找，自然失败 - 启用了
log-bin，但log_bin_index指向的路径不可写，或文件权限不对（errno 13 = 权限拒绝） -
innodb_log_group_home_dir指向的目录不存在，或ib_logfile0被误删后MySQL拒绝自建（尤其在非干净关闭后）
临时解法：注释掉log-bin、server-id等复制相关配置，先让实例起来；长期方案是清理mysql-bin.index内容（清空或重写），或用mysqladmin flush-logs重建binlog序列。
真正难排查的是InnoDB路径问题——它不报错，只默默用默认路径初始化新实例，导致你连上后发现全是空库。所以每次改datadir或innodb_data_home_dir，务必确认原数据已完整迁移、权限已同步、且ibdata1和ib_logfile*都在目标目录下。
