table_open_cache真实生效值受open_files_limit截断，需同时查三组值：table_open_cache、open_files_limit及open_tables/opened_tables比值；若open_tables/table_open_cache长期＞0.95，表明缓存常满、频繁淘汰。
确认当前生效值和系统限制
直接改 my.cnf 之前，先查清楚实际起作用的是什么——table_open_cache 不是设多少就生效多少。MySQL 启动时会把它截断到 open_files_limit 以内，且不报错。你配了 4000，但 open_files_limit 是 2048，那真实值就是 2048。
必须连查三组值：
SHOW VARIABLES LIKE 'table_open_cache';SHOW VARIABLES LIKE 'open_files_limit';SHOW GLOBAL STATUS LIKE 'Open%tables';
重点看 Open_tables 和 Opened_tables 的比值：如果长期 Open_tables / table_open_cache > 0.95，说明缓存常满、频繁淘汰；如果 ，大概率配大了，白占内存。
配置文件里怎么写才真正生效
在 my.cnf 的 [mysqld] 段里写，不能只写数值，得同步控制关联参数：
-
table_open_cache = 2048（按 4G 内存机器常见起点） -
table_open_cache_instances = 8（设为物理 CPU 核数，上限 16；别留默认的 1） -
open_files_limit = 4096（必须 ≥table_open_cache × 1.25，否则前面两个白配）
注意：table_open_cache_instances 和 table_open_cache 是乘积关系，但分片后锁竞争下降明显。高并发下看到大量线程卡在 Opening tables 状态，八成就是它没调。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
为什么不能按 max_connections × 表数量硬算
这个公式在 OLTP 场景下严重高估。一个连接平均打开 2 张表，1000 连接就配 2000？实际可能峰值 Open_tables 只有 600。因为：
- 连接复用表缓存，不是每个新查询都开新表
- 临时表、日志、复制线程也要抢文件描述符
- MySQL 5.6+ 的 LRU 淘汰策略让冷表很快被踢出
更靠谱的做法是：压测或观察生产高峰 1 小时内的 Opened_tables 增量，取最大值再加 20% —— 这才是你要设的 table_open_cache 下限。
云数据库和自建 MySQL 的关键区别
RDS、PolarDB 这类云服务通常已自动调优 table_open_cache 和 table_open_cache_instances，你手动改反而可能触发平台保护机制回滚。但自建 MySQL 必须显式配置，尤其要注意：
- Linux 系统级限制：检查
ulimit -n，若低于open_files_limit，MySQL 启动时会静默降级 - systemd 管理的 MySQL 需额外在
/etc/systemd/system/mysqld.service.d/override.conf里加LimitNOFILE=4096 - 改完必须重启 MySQL，
SET GLOBAL只临时生效，且无法突破open_files_limit上限
最容易被忽略的其实是 table_open_cache_instances —— 它不占内存，却能直接缓解高并发下的 mutex 争用。哪怕你只调了 table_open_cache，没动它，性能提升也会打七折。
