minidle应设为预期最低并发量的30%～50%，maxidle不宜超过maxactive的80%；二者需协同服务端timeout与客户端idletimeout配置，避免冷连接复用失败或资源浪费。
Redis 连接池的 MaxIdle 和 MinIdle 怎么设
这两个参数控制空闲连接数量，直接影响并发请求下的连接复用效率。设得太小（比如 MinIdle=0）会导致高并发时频繁新建连接；设得太大（比如 MaxIdle=1000）又浪费 Redis 服务端资源，还可能触发客户端连接数限制。
实操建议：
-
MinIdle建议设为预期最低并发量的 30%～50%，例如日常 QPS 200，可设MinIdle=60 -
MaxIdle不宜超过MaxActive（或PoolSize）的 80%，避免空闲连接长期占着不放 - Iris 的
redis.PoolConfig中没有MinIdle字段，需通过redis.NewPool手动构造并设置IdleTimeout和MaxIdle，再传给iris.Redis初始化函数
MySQL 连接池在 Iris 里怎么调 SetMaxOpenConns 和 SetMaxIdleConns
Iris 本身不管理 MySQL 连接池，它依赖 database/sql 的原生配置。但很多人误以为在 app.ConfigureHost 里能统一配置，其实不行——必须在初始化 *sql.DB 后立刻调用这两个方法。
常见错误现象：压测时出现 dial tcp: lookup xxx: no such host 或大量 connection refused，往往是因为连接池没调好，导致瞬时新建连接爆炸。
实操建议：
-
SetMaxOpenConns(50)是安全起点，若单次请求平均耗时 100ms，理论可支撑约 500 QPS（50 ÷ 0.1s） -
SetMaxIdleConns(20)建议设为MaxOpenConns的 40% 左右，避免空闲连接过早被 GC 掉 - 务必调用
db.SetConnMaxLifetime(30 * time.Minute)，防止连接因服务端 timeout 被静默断开
为什么 MaxIdle 设太高反而降低 Redis 响应速度
不是连接越多越快。Redis 单线程处理命令，客户端连接数过多会增加内核态 socket 管理开销，尤其在 Linux 上，每个连接占用一个文件描述符，还会加剧 epoll 就绪列表扫描成本。
更隐蔽的问题是：当 MaxIdle 过大，连接池倾向于复用“冷连接”（长时间未通信），而这些连接可能已被 Redis 服务端主动关闭（timeout 配置），结果第一次复用就触发重连+认证，延迟陡增。
实操建议：
- 检查 Redis 服务端
timeout值（默认 0 表示不超时，生产环境建议设为 300 秒） - 客户端
IdleTimeout必须略小于服务端timeout，例如服务端设 300s，客户端设290 * time.Second - 用
redis-cli --latency对比不同MaxIdle下的 P99 延迟，而不是只看平均值
Iris 启动时如何验证连接池是否生效
光看日志没用。Iris 不会打印连接池状态，必须主动探测。最直接的方式是在 HTTP handler 里调用 iris.Redis().PoolStats()（如果用了 iris-contrib/middleware/redis）或自己封装的 *redis.Pool 实例的 Stats() 方法。
实操建议：
- 加一个
/debug/redis-pool路由，返回ActiveCount、IdleCount、WaitCount三项关键指标 - 观察压测中
WaitCount是否持续增长，若是，说明MaxActive不足或连接泄漏（比如忘了conn.Close()） - 注意：Iris 默认不启用连接池统计，需在创建 pool 时显式传入
redis.Pool{Stats: &redis.PoolStats{}}
连接池参数不是设完就一劳永逸的。真实流量下，IdleCount 波动剧烈、WaitCount 偶发突增，往往意味着某类接口没做连接释放，或者缓存穿透导致 DB 连接被长时占用——这些细节比初始数值更重要。
