生产环境必须严格控制basedir、datadir、socket、pid-file四路径归属与权限，否则必然导致启停异常、备份失败、监控失联；/usr/local/mysql不可直接使用，应改用/opt/mysql/mysql-8.0.x软链+独立挂载/datadir，初始化必须用--initialize并立即改密，my.cnf须强制配置character-set-server=utf8mb4、skip_name_resolve=ON、log-error绝对路径。
直接说结论：用官方 mysql-8.0.x-linux-glibc2.12-x86_64.tar.xz 包手动部署 MySQL 8.0，在生产环境里不是“能用就行”，而是必须控制 basedir、datadir、socket、pid-file 四个路径的归属与权限，否则后续启停异常、备份失败、监控连不上都是大概率事件。
为什么不能直接解压到 /usr/local/mysql 并 chown mysql:mysql？
这是最常踩的坑——看似目录权限对了，但实际运行时会报 mysqld: Can't create/write to file '/usr/local/mysql/data/ibdata1' 或启动后立刻退出，日志里只有一句 Aborting。根本原因在于：/usr/local 默认是 root 权限，即使你 chown -R mysql:mysql /usr/local/mysql，systemd 或 init 脚本在以 mysql 用户身份启动时，仍可能因父目录（/usr/local）不可写而拒绝进入子目录。
实操建议：
- 安装路径（
basedir）推荐放在/opt/mysql/mysql-8.0.36，然后用软链/opt/mysql/current → /opt/mysql/mysql-8.0.36，避免硬编码路径 - 数据目录（
datadir）必须独立挂载，如/data/mysql/3306/data，且父目录/data/mysql/3306的 owner 必须是mysql:mysql，权限750 -
socket和pid-file所在目录（比如/data/mysql/3306/run）也需同属mysql，且不能是/tmp或/var/run这类 tmpfs 目录（重启即丢，systemd 无法感知进程状态）
初始化时 --initialize 和 --initialize-insecure 的关键区别
MySQL 8.0 默认强制使用 --initialize（生成随机 root 密码），但很多自动化脚本或 Ansible playbooks 会误用 --initialize-insecure，结果导致后续连接报错 Access denied for user 'root'@'localhost'，哪怕你没设密码。
原因在于：8.0 启动后首次连接必须用初始密码 + ALTER USER ... IDENTIFIED BY 强制改密，这是安全策略硬约束。而 --initialize-insecure 在 8.0 中已不推荐，且某些补丁版本会直接拒绝该参数。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 始终用
mysqld --defaults-file=/data/mysql/3306/my.cnf --initialize --user=mysql - 初始化完成后立即查日志找密码：
grep 'temporary password' /data/mysql/3306/logs/error.log - 不要跳过改密步骤，否则下次 mysqld_safe 自动重启时会卡在认证环节
my.cnf 里最容易被忽略的三个强制项
很多配置模板抄来就用，但漏掉这三个参数，轻则慢查询日志不写，重则主从同步中断、备份工具（如 mydumper）直接报错退出。
必须显式声明：
-
character-set-server=utf8mb4：MySQL 8.0 默认 collation 是utf8mb4_0900_ai_ci，但若配置里没设character-set-server，客户端连接时可能 fallback 到latin1，导致插入中文变 ? -
skip_name_resolve=ON：禁用 DNS 反查，否则高并发下host_cache会打满，连接建立延迟飙升，错误日志频繁出现Host 'xxx' is blocked because of many connection errors -
log-error=/data/mysql/3306/logs/error.log：必须绝对路径，且该文件不能由 mysqld 自己创建（要提前 touch + chown），否则启动失败且无明确提示
启动失败时，先看这三行日志再动手重装
别急着删 data 目录重来。90% 的启动失败问题，都能从 error log 开头几行定位：
- 如果第一行是
InnoDB: The log file size is smaller than the buffer pool size：说明innodb_log_file_size太小，需满足 ≥innodb_buffer_pool_size / 4，且修改后必须清空ib_logfile*（不是删整个 data 目录） - 如果出现
Can't start server : Bind on unix socket: Permission denied：检查socket=/data/mysql/3306/run/mysql.sock对应目录权限，确认mysql用户对该目录有w权限，且 SELinux 状态为permissive（非enforcing） - 如果日志停在
Starting completion of delayed initialization就不动：大概率是datadir下残留了旧版 ibdata1 或未清理干净的mysql系统库，此时应比对mysqld --verbose --help | grep "Default options"确认实际读取的配置文件路径，再检查该配置是否真被加载
真正麻烦的从来不是“装不上”，而是“以为装上了，其实只跑了半步”。比如 lower_case_table_names=1 必须在初始化前定死，初始化后再改等于重装；又比如 server-id 在单机部署时看似无关紧要，但一旦后续加从库或开启 GTID，缺它就会卡在 Waiting for master to send event。这些点不写进脚本、不验进 checklist，靠人记，迟早出事。
