MySQL 启动时按固定顺序读取配置文件，优先级为 /etc/my.cnf → /etc/mysql/my.cnf → /usr/local/mysql/etc/my.cnf → ~/.my.cnf，后加载的覆盖前序；执行 mysqld --help --verbose | grep "Default options" 可确认实际加载路径，再用 grep -n 定位参数生效位置。
生产环境的 my.cnf 参数不能照搬模板，必须基于硬件资源、业务特征和故障容忍度做取舍。盲目调大 innodb_buffer_pool_size 或设 innodb_flush_log_at_trx_commit=0，轻则性能不升反降，重则丢数据。
怎么确认 MySQL 正在读哪个 my.cnf 文件
MySQL 启动时按固定顺序加载多个配置文件，后加载的会覆盖前面的 —— 这是“改了配置却不生效”的最常见原因。
- 执行
mysqld --help --verbose | grep "Default options"，输出类似：Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf - 优先检查
/etc/my.cnf和/etc/mysql/my.cnf（Ubuntu 常见路径）；CentOS 7 默认走/etc/my.cnf - 如果多个文件都存在，用
grep -n "innodb_buffer_pool_size" /etc/my.cnf /etc/mysql/my.cnf定位实际生效位置 - 修改前务必备份：例如
sudo cp /etc/mysql/my.cnf /etc/mysql/my.cnf.bak-$(date +%Y%m%d)
innodb_buffer_pool_size 设多大才安全
它是影响性能最敏感的参数，但设错会直接触发 OOM Killer 杀 MySQL 进程。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 计算公式不是“总内存 × 70%”，而是：预留至少 2~4GB 给系统 + 其他进程（如 Redis、Nginx），再分配剩余部分
- 8GB 内存服务器：建议 ≤ 4.5G（即
innodb_buffer_pool_size = 4500M），而非盲目设 6G - 256GB 内存服务器：可设到 192G，但需同步检查
vm.swappiness是否为 1，避免交换分区拖慢响应 - 搭配
innodb_buffer_pool_instances = 8（当 buffer_pool > 4G 时），减少内部锁争用
日志与事务参数怎么平衡写入性能和数据安全
高并发写场景下，innodb_log_file_size 和 innodb_flush_log_at_trx_commit 必须协同调整，单独改一个没用。
-
innodb_log_file_size推荐值：取innodb_buffer_pool_size的 25% 左右，但上限建议 ≤ 4G（如 6G buffer_pool → 设 1536M）；超过 4G 会导致崩溃恢复时间显著拉长 -
innodb_flush_log_at_trx_commit：- 值为 1：每次
COMMIT都刷盘，数据零丢失，但 QPS 明显受限 - 值为 2：日志写入 OS 缓存，每秒刷一次，崩溃可能丢最多 1 秒数据，适合订单类非金融核心链路
- 值为 0：完全依赖 OS 刷盘，风险最高，仅限日志类、分析类等可丢数据场景
- 值为 1：每次
- 若选 2，必须配
sync_binlog = 1000（而非 0 或 1），否则主从复制可能因 binlog 和 redo 日志不一致而断裂
哪些参数在 MySQL 8.0 中已失效或行为变更
沿用 MySQL 5.7 的配置直接套到 8.0 上，大概率引发启动失败或隐性故障。
-
query_cache_type：MySQL 8.0 已彻底移除，配置中出现该行会导致mysqld启动报错unknown variable 'query_cache_type' -
default_authentication_plugin：8.0 默认是caching_sha2_password，如果应用连接驱动太旧（如 mysql-connector-java < 8.0.11），会报Client does not support authentication protocol -
character-set-server必须设为utf8mb4，utf8是 MySQL 的陷阱别名（只支持 3 字节 UTF-8），设错会导致 emoji 插入失败或乱码 -
max_connections调高后，必须同步调整系统级限制：/etc/security/limits.conf中mysql soft nofile和hard nofile至少设为该值的 2 倍，否则 MySQL 会静默拒绝新连接
真正难的不是记住参数值，而是理解每个参数在你的磁盘 I/O 模式、网络延迟、应用重试逻辑下的实际表现 —— 比如 innodb_log_file_size 调大后写入变快了，但主库 crash 后从库追日志的时间是否仍在 SLA 内？这类判断没法靠文档，只能靠压测和监控反馈。
