flushdb async 更适合测试环境，因其异步清空当前库不阻塞服务，但仅支持 redis 4.0+；需确认实例、数据库编号及 aof 策略，否则易误删或性能异常。
FLUSHDB ASYNC 能安全清空当前数据库且不阻塞 Redis 服务，但仅适用于 Redis 4.0+，低于该版本会报错并退化为同步操作。
为什么 FLUSHDB ASYNC 比 FLUSHDB 更适合测试环境
测试环境常需高频重置数据，而 FLUSHDB 是同步操作：它会遍历并逐个删除所有 key，期间 Redis 主线程完全阻塞，大库下可能卡住数秒甚至更久，导致客户端超时或连接堆积。而 FLUSHDB ASYNC 把实际释放内存的工作交给后台线程异步执行，命令返回即刻完成，客户端无感知。
- 适用前提：Redis 版本 ≥ 4.0（可通过
redis-server --version或INFO server中的redis_version确认） - 不释放内存？不是 —— 它只是“延迟释放”，key 的内存会在后台逐步回收，
INFO memory中的used_memory会缓慢下降 - 注意：它只清当前
SELECT的数据库（如SELECT 1后执行，只清 db1），不是全实例
执行前必须检查的三个关键点
跳过这些检查，可能误删生产数据、触发 OOM 或命令静默失败。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 确认连接的是测试实例：用
CLIENT LIST查addr，或在连接 URL 中核对 host/port；避免在共享集群中误操作 - 确认当前数据库编号：运行
INFO keyspace，看类似db0:keys=1234,expires=56,avg_ttl=123456的行，确保目标库非空且是你想清的库 - 检查是否启用了 AOF + always：若
appendfsync always开启，FLUSHDB ASYNC仍会强制 fsync 一次（虽不阻塞删除，但可能延长写盘时间）；测试环境建议设为no或everysec
常见错误现象与对应处理
命令返回异常或效果不符，往往不是语法问题，而是环境或权限限制。
-
(error) ERR unknown command `FLUSHDB`, with args beginning with: `ASYNC`→ Redis 版本太低（FLUSHDB 并接受短时阻塞，或升级实例 - 执行后
used_memory几乎不变，且INFO stats中evicted_keys突增 → 可能开启了 maxmemory + LRU 策略，Redis 在后台清理时被内存策略抢先淘汰了部分 key，属正常现象 - 使用 redis-cli 执行无响应 → 检查是否漏写了
ASYNC（写成FLUSHDB就会卡住），或网络中断导致连接假死，可加-h/-p显式指定地址重试
替代方案对比：什么情况下不该用 FLUSHDB ASYNC
它不是万能解药，某些场景下反而更慢或不可控。
- 需要立即释放全部内存（如压测前强制归零）→ 改用
CONFIG SET maxmemory 1再FLUSHDB，触发即时驱逐（慎用，可能丢数据） - 要清多个库（如 db0–db3）→
FLUSHALL ASYNC更合适，但注意它清整个实例，权限和影响面更大 - 使用 Redis Cluster →
FLUSHDB ASYNC不支持，只能在每个 master 节点上单独执行，且需确保 slot 分布不导致跨节点误操作
真正容易被忽略的是：异步清理期间，如果恰好有大量新 key 写入同一数据库，内存可能不降反升——因为旧 key 还没释放完，新 key 又进来了。测试脚本里清库后别立刻压测，等 INFO memory 的 used_memory 稳定回落再开始。
