-
dump.rdb文件越积越多是因为Redis默认不自动清理旧快照，每次bgsave生成新文件但保留旧文件，需依赖外部脚本按时间戳安全清理。
-
Redis6.0+的Pub/Sub不阻塞主线程，因消息分发改由独立客户端上下文异步处理；而5.x及更早版本中publish同步遍历订阅者，网络慢或缓冲区满时会阻塞主线程。
-
SDIFF不能直接找出“新增关注”，因其仅执行集合差运算且不记录时间顺序；需先构建两个语义明确的快照集合（如按日期命名），再用SDIFF计算差集，否则易因键名错误、空键或客户端处理问题导致结果异常。
-
哨兵节点启用密码认证但未提供密码导致SENTINELmaster报NOAUTH错误；需在sentinel.conf中配置sentinelauth-pass，并手动auth；注意端口、master-name一致性及flags等字段含义。
-
RedisLua脚本中不能直接执行SET等命令，必须通过redis.call()或redis.pcall()调用；MULTI/EXEC等事务命令禁用；所有key需显式传入，集群下须同slot；返回值类型需手动判断，避免误判false/0。
-
正确做法是用EVAL执行Lua脚本保证原子性，结合PTTL和TIME实现毫秒级令牌补充，避免客户端时间依赖；Redis6.2+可用CL.THROTTLE简化实现。
-
会，大量key同时过期会引发CPU尖峰、内存延迟释放和请求抖动；Redis通过每100ms随机抽样检查过期key，超25%过期则连续多轮高强度扫描删除，导致延迟飙升甚至超时。
-
Redis主从心跳由应用层PING和REPLCONFACK命令维持，主库每秒发PING，从库需立即回ACK；若超repl-timeout（默认60秒）未收到ACK，主库即标记该从库为down。
-
常用的Redis性能监控工具包括Redis自带的INFO命令、慢查询日志、RedisInsight、Prometheus和Grafana组合以及Redis-benchmark。1.INFO命令适合快速诊断问题，但数据粒度较粗。2.慢查询日志有助于优化性能，但配置需谨慎。3.RedisInsight提供直观的监控和分析功能，但需考虑资源消耗。4.Prometheus和Grafana组合适用于大规模集群监控和长期趋势分析，部署复杂。5.Redis-benchmark用于测试性能极限，需结合实际业务场景分析。
-
<p>MySQL数据库创建的完整流程包括规划、命名、创建数据库、创建表、权限管理和最佳实践。1.规划时需考虑数据类型、规模、访问频率和扩展性。2.命名应简洁明了并与项目一致，如"projectx_db"。3.使用SQL命令创建数据库并设置字符集和排序规则，如CREATEDATABASEprojectx_dbCHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ci;。4.创建表时遵循规范化设计，避免数据冗余，如CREATETABLEusers(idINTAUTO_
-
切换RedisPython客户端需同步更新依赖和初始化代码，仅安装新包不生效；redis-py不支持集群，redis-py-cluster已停更，应改用redis-py4.0+的RedisCluster；异步场景下aioredisv1与v2接口不兼容。
-
Redis自动快照由save指令控制，需满足“指定时间内发生指定次数写操作”才触发，如save9001表示900秒内至少1次修改；仅注释或修改redis.conf不生效，必须重启或重载配置，且CONFIGSET无法动态修改save参数。
-
RedisPub/Sub超时主因是TCP连接中断或服务端阻塞，需独立配置订阅连接、启用tcp-keepalive、禁用中间设备断连，并监控blocked_clients与slowlog。
-
根本原因是MOVE命令迁移大Key时需原子性搬运整个value并阻塞slot读写；应通过业务层拆分（如SCAN+HSCAN）、人工slot迁移及提前识别大Key来解决，而非依赖reshard。
-
单靠DECR会超卖，因其校验库存是否>0与扣减是两步非原子操作，高并发下多个客户端可能同时读到库存=1后均执行DECR导致负数；必须用Lua脚本将判断与扣减封装为单次原子执行。
