-
noeviction策略下写操作直接报错是因为内存达maxmemory后硬性拒绝所有写命令，不释放key也不等待，仅允许读操作，导致“能读不能写”现象。
-
从 MySQL 8.4 Skip Scan 入手，讲清复合索引没有左前缀条件时优化器为什么仍可能走索引，以及如何用 EXPLAIN ANALYZE 和 optimizer_switch 做生产验证。
-
LPUSH+LPOP无法自动限长，因LPOP删队首而新元素入队尾，导致长度持续增长；唯一可靠方式是LPUSH后立即LTRIM，或用Lua脚本原子执行推入与截断。
-
选择合适的MySQL数据类型能节省存储空间、提升查询性能并确保数据准确性。常见的数据类型分为数值型（如INT、DECIMAL）、字符串型（如CHAR、VARCHAR）和日期时间型（如DATE、DATETIME、TIMESTAMP）。选择时应遵循几个关键点：1.节省存储空间，如状态字段用TINYINT；2.提高查询效率，优先使用定长类型；3.避免精度丢失，金额字段用DECIMAL；4.注意默认行为差异，如TIMESTAMP自动处理时区。常见场景推荐：用户ID用INTUNSIGNED或BIGINT，用户名用V
-
“永不过期”策略实质是Rediskey物理永存，逻辑过期时间嵌入value中；安全的get_with_logic_expire需用SETNX抢锁、双重检查、异步更新；必须搭配主动刷新机制防脏数据。
-
Redis自动RDB备份不能仅用crontab调用bgsave，因BGSAVE异步返回OK不保证写入完成，需校验rdb_last_save_time和文件非空，并动态获取路径、加超时、轮转清理。
-
AOF重写后文件变大是因为重写时仍会写入带过期时间但尚未过期的key，尤其高频短TTL的SET/EXPIREAT等指令堆积且无法压缩，导致AOF体积膨胀。
-
推荐用base64url编码6字节随机数生成短码，冲突概率低且不可预测；需先EXISTS校验再写入，跳转用Lua脚本原子读URL并INCR计数，Redis用String类型存short:{code}→URL，设EX过期，stat:{code}单独存访问量。
-
Redis“无条件刷新”实为业务代码显式执行SET/SETEX覆盖key，需确保写路径确定、key名准确、实例正确；禁用SETNX，慎用GETSET；批量操作须防pipeline/事务失败导致缓存未更新；穿透雪崩时应加空值缓存与随机TTL而非强行刷新。
-
Redis内存飙升多因bigkey，应优先在从节点用redis-cli--bigkeys扫描，避免主节点阻塞；它仅返回每类最大key且不反映真实内存，需结合MEMORYUSAGE和访问频次进一步分析。
-
RedisLua脚本中不能直接执行SET等命令，必须通过redis.call()或redis.pcall()调用；MULTI/EXEC等事务命令禁用；所有key需显式传入，集群下须同slot；返回值类型需手动判断，避免误判false/0。
-
InnoDB适配事务与高并发场景，MyISAM适合读多写少需求。1.InnoDB支持事务，确保数据一致性，MyISAM不支持；2.InnoDB使用行锁提升并发性能，MyISAM使用表锁限制并发；3.InnoDB具备崩溃恢复能力，而MyISAM需手动修复；4.InnoDB支持全文索引，功能已超越MyISAM；因此，需事务、高并发、数据安全的场景优先选InnoDB，若仅读多写少且追求查询性能可考虑MyISAM，但其维护成本较高，MySQL默认引擎为InnoDB，推荐现代应用广泛使用。
-
缓存空值TTL推荐2–5分钟，用SETEX或set(key,"NULL",300,TimeUnit.SECONDS)，避免永不过期或24小时；内容用"NULL"等明确标记，前置参数校验更早拦截无效请求。
-
ZADD的score不能用时间戳，因同分排序不稳定且时间戳递增违背“分数越高名次越靠前”逻辑；应使用业务分数（如积分）并利用ZADD覆盖更新、ZINCRBY原子累加、ZREM安全删除。
-
RedisPub/Sub不适合异步任务处理，因其无确认机制、无持久化、不支持消费者组与积压缓冲；应选用LPUSH+BRPOP或XADD+XREADGROUP(Stream)实现可靠任务队列。
