redis执行lua脚本时读取大value会阻塞主线程，导致延迟飙升、qps骤降；应避免在lua中处理大字符串，优先使用原生命令或客户端处理，并分离读取与解析逻辑。
redis.call() 读大Value会卡住整个Redis主线程
Redis 执行 Lua 脚本是单线程的，一旦 redis.call('GET', KEYS[1]) 读取一个超过 100KB 的字符串，不仅网络传输慢、内存拷贝多，更致命的是：这个操作会**阻塞所有其他客户端请求**，直到脚本执行完。实测中，读取 500KB 的 value 可导致平均延迟从 0.2ms 拉升到 80ms+，且期间 INFO stats 中的 instantaneous_ops_per_sec 掉到接近 0。
- 大 Value 标准参考：String 类型 >10KB，Hash/List/Set/ZSet 元素总数 >5000 或单个 field value >1KB
- 别指望压缩能完全解决——
string.gsub或string.match处理大字符串本身也吃 CPU，尤其带正则时 - Redis 默认
lua-time-limit 5000（5 秒），但大 Value 读取 + 字符串处理很容易超时，触发SCRIPT KILL，而强制 kill 可能留下不一致状态
用 Redis 原生命令替代 Lua 字符串处理
只要不是必须在服务端做语义解析（比如 JSON 内容过滤），就该把字符串操作移出 Lua。Redis 提供了足够多的原子命令来规避大部分“先取再改再存”的陷阱。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 需要截取前缀？用
GETRANGE key 0 99，而不是redis.call('GET', key)后在 Lua 里string.sub(val, 1, 100) - 需要判断是否包含某子串？优先用
STRALGO LCS（Redis 7.0+）或业务层加前缀索引，而非string.find(val, pattern) - 需要大小写转换？除非极简场景（如统一转小写做 key 归一），否则避免
string.upper()/string.lower()—— 客户端做更快、更可控 - 需要拼接或格式化？传入已拼好的完整字符串，别在脚本里做
val .. ':' .. os.time()；时间戳由客户端生成并传入ARGV
拆分逻辑：把大Value读取和处理分离
当真无法绕过大 Value 处理（例如日志归档、协议头解析），不要在一个脚本里完成“读→解析→修改→写回”。把耗时部分下沉或前置，让 Lua 只做原子决策。
- 方案一（推荐）：客户端先用
GET拿 value → 在本地解析/裁剪 → 把结果传给轻量脚本执行原子写入，例如：EVALSHA <sha> 1 mykey ARGV[1]=trimmed_payload</sha> - 方案二：用
GETRANGE+SETRANGE分块操作，避免一次性加载全量；注意SETRANGE对超出范围的填充用\x00，需确认业务是否可接受 - 方案三：对大 Value 建立摘要，如存
SET mykey:digest SHA256(payload)，Lua 脚本只比对 digest，真正 payload 存对象存储或本地缓存
为什么 string.len() 和 string.sub() 在大字符串上也慢
很多人以为纯 Lua 函数不碰 Redis 就安全，但 string.len() 和 string.sub() 在 Redis 内嵌 Lua 5.1 解释器中，对长字符串仍需遍历字节或构建新副本。测试显示：对 200KB 字符串调用一次 string.sub(s, 1, 10) 平均耗时 0.15ms，100 次就是 15ms —— 已超过多数接口 P99 要求。
- 别在循环里反复调用
string.len(val)，存成局部变量local l = #val（#比string.len()快 3–5 倍） - 避免
string.sub(val, start, end)返回新字符串副本；如只需判断前缀，用string.match(val, "^prefix.*")更省内存（但慎用复杂正则） - Redis 未启用
lua-time-limit保护时，这类操作不会报错，但会悄悄拖垮整体吞吐——监控latency doctor和SLOWLOG GET是唯一办法
