host_cache_size在mysql 5.6.5+才生效，需配置在[mysqld]段并重启mysqld；它仅影响新连接阶段的dns解析与错误统计，非查询缓存或连接池，盲目调大无益且浪费内存。
host_cache_size 设置无效？先确认 MySQL 版本和启动方式
MySQL 5.6.5+ 才真正启用 host_cache_size，低于这个版本设了也白设——变量存在但不生效。更常见的是：你改了配置文件却没用 mysqld 重新加载，或者压根没加到正确的配置段里。
- 检查版本：
SELECT VERSION();，确认 ≥ 5.6.5 - 确认配置写在
[mysqld]段下，不是[client]或其他段 - 修改后必须重启
mysqld（SET GLOBAL不支持动态修改host_cache_size） - 验证是否生效：
SHOW VARIABLES LIKE 'host_cache_size';，值应与配置一致
host_cache 是什么？为什么调它不如先查连接来源
host_cache 不是查询缓存，也不是连接池，它是 MySQL 内部维护的一张内存表，记录最近尝试连接的客户端 IP、主机名解析结果、错误计数等，用于加速反向 DNS 查询和限制失败连接频率（比如 max_connect_errors 判定）。
- 它只影响“新连接建立阶段”，对已建立连接的查询完全无感
- 如果你看到大量
Host 'xxx' is blocked because of many connection errors，才值得动它 - 盲目调大
host_cache_size不解决根本问题——更可能是应用没复用连接、或存在扫描类探测流量 - 默认值通常是 128，够大多数中小业务用；超过 1000 的设置需谨慎，内存占用线性增长且无收益
怎么安全地调整 host_cache_size？别直接写死数字
硬编码一个大数字（比如 2048）容易掩盖真实问题，也浪费内存。更稳妥的做法是结合监控观察实际使用率。
- 查当前缓存使用情况：
SELECT * FROM performance_schema.host_cache; - 重点关注
HIGH_NUMBER_OF_CONNECTION_ERRORS和HOST列，看哪些 IP 错误集中 - 用
SELECT COUNT(*) FROM performance_schema.host_cache;看当前条目数，若长期 - 如果确需调大，建议按 128 → 256 → 512 逐步试，每次重启后观察 24 小时内错误日志和连接行为
- 配合
skip_name_resolve=ON可彻底绕过主机名解析，让host_cache失去作用——这才是很多场景下的更优解
容易被忽略的副作用：DNS 超时会卡住整个连接流程
很多人以为 host_cache 只是“记个账”，其实它直接影响连接建立的阻塞时间。当 MySQL 尝试反向解析客户端 IP 时，若 DNS 响应慢或不可达，host_cache 会等超时（默认 30 秒），期间该连接线程挂起，可能拖垮连接池。
- 这不是
host_cache_size能解决的问题，而是架构层面要规避的 - 生产环境强烈建议在 my.cnf 中显式配置
skip_name_resolve=ON，强制用 IP 认证，既提速又省心 - 开启
skip_name_resolve后，host_cache仍存在，但不再做 DNS 查询，只记录 IP 和错误次数，行为更可预测 - 注意：开启后所有
GRANT语句里的'user'@'hostname'必须改成'user'@'ip_address'或'user'@'%'，否则权限不生效
事情说清了就结束
