levels参数不提升单次查找速度，但通过哈希分层（如1:2）将百万级缓存均匀分散至4096个子目录，避免单目录文件过多导致ext4/xfs查找延迟激增，并需配合keys_zone、inactive、use_temp_path及挂载选项等调优才能生效。
直接说结论：levels 参数不提升单次文件查找速度，但能极大缓解高并发下因单目录文件过多引发的 I/O 延迟。核心是用哈希分层把海量缓存文件均匀打散，避免一个目录塞进上万文件，让文件系统不用在超大目录里“大海捞针”。
为什么 levels=0 在大规模缓存下会变慢
不设 levels（即 levels=0）时，所有缓存文件都堆在同一个目录里。当缓存条目超过 10 万，ext4 或 xfs 文件系统就会明显吃力：
- ext4 默认用线性扫描查目录项，文件越多，每次 stat/open 耗时越长
- xfs 的 dir2 结构在单目录超数万文件后，目录块分裂频繁，查找开销上升
- Nginx 每次缓存命中都要读取文件元数据，高频小文件 I/O 下，瓶颈立刻暴露在磁盘层，不是 Nginx 本身慢
推荐用 levels=1:2，而不是其他组合
这是当前最平衡、最实用的分层方案：
- 按缓存 key 的 MD5 哈希值前三位生成路径，比如 /var/cache/nginx/mycache/a/1b/a1b2c3
- 第一级 16 个目录（0–f），第二级每个再分 256 个（00–ff），共 4096 个叶子目录
- 百万级缓存下，每个目录平均仅几百个文件，目录查找基本稳定在常数时间
- 相比 levels=2:2（65536 目录），它更轻量，管理成本低，且足够应对绝大多数业务规模
- 固定哈希映射带来局部性优势：相同请求总落在同一子目录，利于 page cache 复用和磁盘预读
只配 levels 不够，必须同步调优配套参数
单独设置 levels=1:2 效果有限，要配合以下几项才能真正释放性能：
- keys_zone 至少 10m：约支持 8 万个活跃缓存项；太小会导致 key 冲突频繁淘汰
- inactive 别设太短：如仅 60s，会触发高频清理重建，加剧 I/O；建议按业务热度设为 30m–2h
- use_temp_path=off：让临时文件直接写入缓存目录，避免跨文件系统 copy，省一次磁盘写
- 挂载选项优化：SSD 上推荐 noatime,nobarrier（xfs）或 noatime,commit=60（ext4），减少元数据刷盘开销
缓存 key 设计决定 levels 是否真正有效
levels 路径由 cache_key 经 MD5 后取前几位生成。如果 key 包含高熵字段，哈希会严重不均：
- 含时间戳、随机串、用户 session ID 等，会导致某些子目录爆满、另一些长期空置
- 结果仍是局部 I/O 压力集中，levels 白配
- 推荐构造稳定 key：$scheme$host$request_uri，去掉动态参数
- 避免使用 $request_time、$cookie_sessionid 这类每次都不一样的字段
- 可通过日志统计各子目录文件数量，验证分布是否均衡
