MySQL多实例部署必须手动隔离资源，每个实例需独立datadir、port、socket及server-id；innodb_buffer_pool_size须按比例硬限制（如64GB内存下每实例≤8GB），禁用performance_schema并配置systemd MemoryLimit防OOM。
能部署，但必须手动隔离资源边界，MySQL本身不感知“多实例”，只认单个mysqld进程的配置。4个实例不是简单复制粘贴就能跑通，核心矛盾是内存、I/O和CPU争抢——尤其innodb_buffer_pool_size设错，一个实例吃光内存，其他全卡死。
每个实例必须有独立的datadir、port和socket
这是启动成功的底线。缺一不可，且不能复用默认路径或端口。
-
datadir必须各自初始化：比如/var/lib/mysql3307、/var/lib/mysql3308等，属主为mysql用户，权限750 - 端口不能重叠：推荐从
3307起跳，避开3306（避免误连生产），也别用3309以上——某些云厂商防火墙默认拦截高位端口 -
socket文件路径必须唯一：如/tmp/mysql_3307.sock，否则mysql -S会连错实例，连上却查不到库是常见迷惑行为 - 千万别用
cp -r /var/lib/mysql /var/lib/mysql3307来“复制数据目录”——系统表空间、server-uuid、auto.cnf全一样，后续GTID或主从直接报错
内存参数必须按比例硬限制，不能靠系统自动分配
MySQL 8.0+默认innodb_buffer_pool_size可能占物理内存70%以上，4个实例若都默认，加起来远超100%，OS开始OOM kill进程。
- 假设机器有64GB内存，建议给每个实例分配≤8GB
innodb_buffer_pool_size，留至少16GB给OS和其他服务 - 必须显式配置
max_connections（如200），否则默认151，4个实例共604连接，可能触发系统级ulimit -n限制 -
table_open_cache和open_files_limit也要同步调低，否则Too many open files错误在高并发时秒出 - 禁用
performance_schema（设为OFF）可省下每个实例约200MB内存，测试环境可接受
用systemd管理时，ExecStart必须绑定--defaults-file
很多人复制mysqld.service改名后，systemctl start mysqld@3307仍加载/etc/my.cnf，因为没改ExecStart里的参数。
- Unit文件中必须写死：
ExecStart=/usr/sbin/mysqld --defaults-file=/etc/my_3307.cnf - 别依赖
%i自动替换路径——mysqld不支持这种语法，那是mysqld_multi的机制，而mysqld_multi已弃用且不稳定 - 每个Unit的
LimitNOFILE和MemoryLimit建议单独设，例如MemoryLimit=8G，防止某个实例突发内存泄漏拖垮整机 - 检查
systemctl show mysqld@3307 | grep ExecStart，确认输出里真包含你写的--defaults-file路径
连接与验证阶段最容易忽略server-id和日志路径
刚启动时能连上、能建库，不代表能长期稳定——server-id重复或日志混写，会在开启binlog或未来做主从时暴雷。
- 每个实例
server-id必须全局唯一，推荐用端口号衍生：如3307对应server-id = 3307 -
log-error、slow_query_log_file、general_log_file全部指向独立路径，否则4个实例往同一个文件狂写，日志完全不可读 - 验证是否真隔离：连上
3307后执行SELECT @@port, @@socket, @@datadir;，三值必须和配置文件一致 - 别信
ps aux | grep mysqld看到多个进程就以为成功——要netstat -tlnp | grep :330[7-9]确认监听端口真实存在
真正麻烦的不是启动，而是后续监控和资源扰动。比如一个实例突然执行大表ALTER，磁盘I/O打满，其他三个实例响应延迟飙升，但top里看不出明显CPU占用——这种问题不会报错，只会让你半夜被告警叫醒。
