-
Redis碎片率超1.5时响应变慢甚至雪崩，根本原因是jemalloc在不连续空闲块中反复查找合适内存块，导致分配延迟升高、CPU波动、GC压力上升并可能引发级联雪崩。
-
根本原因是JedisSentinelPool未真正启用自动发现机制；必须显式设置setTestOnBorrow(true)、传入至少两个可达哨兵地址、调大sentinelMonitorInterval，否则轮询不触发重建且DNS/连接复用导致持续连旧主。
-
ZADD的score不能用时间戳，因同分排序不稳定且时间戳递增违背“分数越高名次越靠前”逻辑；应使用业务分数（如积分）并利用ZADD覆盖更新、ZINCRBY原子累加、ZREM安全删除。
-
Redis连接空闲后收不到数据主因是防火墙/NAT静默丢包，须主从节点均配置tcp-keepalive300并重启生效；该参数控制空闲300秒后发首探，不读取内核参数，需ss-tnp验证timer列是否显示keepalive。
-
FUNCTIONLOAD将函数库作为数据库对象持久化并复制，SCRIPTLOAD仅内存缓存脚本且不落盘、不复制；前者支持高可用与跨节点复用，后者重启或主从切换后即失效。
-
应立即将maxmemory-policy从allkeys-lru切回volatile-lru，但需先停写、确认内存未满，再执行CONFIGSET与REWRITE，并配合RDB恢复关键数据，否则残留无TTLkey将持续引发淘汰。
-
RedisLua脚本需用原子“读-判-写”实现状态变迁，推荐HASH结构存储多字段（如status、updated_at、version），通过HGETALL/HSET原子操作，结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转，返回结构化结果便于业务判断。
-
RedisTemplate操作Hash返回null的主因是序列化器不一致：key、hashKey、value三者序列化方式必须匹配，尤其hashKey须用StringRedisSerializer，value推荐Jackson序列化，否则反序列化失败或读不到数据。
-
Redis6.0多线程不加速命令执行，仅I/O多线程+pipeline组合可提升导入效率；需客户端用pipeline打包发送，且主线程不饱和时才有效。
-
缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略：空值需设短过期并避免null值；布隆过滤器须预估容量、全局单例且配合写库更新；业务层应优先校验参数合法性。
-
Redis6+的io-threads应设为2~8，不超过磁盘队列深度的2倍，且必须保持io-threads-do-readsno；它仅加速写入内核页缓存，不加速fsync，设得过多反而加剧IOWAIT和延迟。
-
能，但仅限Redis服务器端EVAL/EVALSHA上下文；需用正确日志级别常量和预拼接字符串，且依赖redis.conf中loglevel和logfile配置生效。
-
MySQL中常见的Join类型包括INNERJOIN、LEFTJOIN、RIGHTJOIN和CROSSJOIN，INNERJOIN性能最佳。INNERJOIN返回两表匹配行，LEFTJOIN返回左表全部记录，RIGHTJOIN返回右表全部记录，CROSSJOIN返回笛卡尔积。Join查询慢的原因主要有：缺少索引导致全表扫描、字段类型不一致无法使用索引、表数据量过大、Join层级或字段过多、驱动表选择不合理。优化方法包括：1.为Join字段加索引，尤其是主键和外键；2.控制Join规模，提前过滤减少数据量；
-
INFOkeyspace无法反映淘汰情况，因其仅统计存活key数量，不区分已过期未删除或已被淘汰的key，且不记录evicted_keys等关键淘汰指标。
-
预热不充分指预热数据未覆盖真实热点、未执行完或未及时更新，导致上线后2–5分钟内缓存击穿；须用线上采样等动态数据源、分批超时控制、命中率校验及事件驱动机制。
