直接看INFO cpu中used_cpu_user和used_cpu_sys是否持续高于80%，若高则说明Lua并发排队导致CPU占满；配合观察evicted_keys或expired_keys是否异常上升，确认其他命令被阻塞未执行；勿轻信redis-cli --latency低延迟假象。
怎么看 EVAL 有没有把 Redis CPU 拖满
直接看 INFO cpu 里的 used_cpu_user 和 used_cpu_sys，持续高于 80% 就是 Lua 在吃 CPU。注意：这不是因为脚本算得慢，而是大量 EVAL 请求在排队等执行——Redis 单线程串行跑脚本，100 个并发进来，哪怕每个只花 2ms，也要排队等 200ms，CPU 时间自然被占满。
配合看 INFO stats 里的 evicted_keys 或 expired_keys 是否异常上升：说明其他命令（比如 SET、GET）被卡在队列里出不去，不是延迟高，是根本没轮到执行。
别信 redis-cli --latency 显示“延迟低”就放心——它测的是 PING 延迟，而 Lua 脚本阻塞的是整个命令执行队列，PING 不走脚本路径，完全不反映真实压力。
用 redis-cli --ldb 定位耗时操作点
redis-cli --ldb --eval script.lua key1 key2 , arg1 arg2 可以进交互式调试模式，逐行单步执行 Lua 脚本。重点观察：
- 哪一行
redis.call()耗时明显（比如查大 hash、遍历 list） - 是否在循环里反复调
redis.call('GET', ...)而没缓存结果 - 有没有
for i = 1, 10000 do这类纯计算循环（Redis 不限制循环次数，只靠lua-time-limit超时中断）
注意：--ldb 会阻塞当前连接，生产环境慎用；建议先在测试实例复现再调试。
EVALSHA 真的省 CPU 吗？关键看这三件事
EVALSHA 只省脚本解析开销，不省运行时 CPU。但它能避免重复编译，对高频小脚本（如原子计数）效果明显。要让它真正生效，必须做到：
- 启动时用
SCRIPT LOAD预加载，把返回的 SHA1 缓存在应用层（不能每次请求都现场SCRIPT LOAD） - 调
EVALSHA后检查返回值是不是NOSCRIPT，遇到就 fallback 到EVAL并重新SCRIPT LOAD - 集群环境下，
SCRIPT LOAD必须发到目标 key 所在 slot 的节点，否则其他节点查不到这个 SHA1
漏掉任意一步，EVALSHA 就退化成 EVAL，白忙活。
哪些 Lua 操作一上线就该砍掉
以下三类操作对单线程 CPU 是“核弹级”风险，优先级最高，必须移出 Redis：
-
redis.call('KEYS', '*')或redis.call('SCAN', ...)：服务端全量扫描，O(N) 且不可中断，主线程直接卡死 -
for i = 1, 5000 do redis.call('HGET', KEYS[1], ARGV[i]) end：应改用redis.call('HMGET', KEYS[1], unpack(ARGV)) -
local res = redis.pcall('GET', key); table.insert(results, res)在大循环里反复调用：错误表累积不释放，Lua 栈内存暴涨，极易触发 OOM
真正难处理的不是脚本写得多复杂，而是“以为自己在优化，其实把压力全压在了单线程上”。比如用 Lua 做分页拼接、日志聚合、JSON 解析——这些本该由客户端或中间层干的事，硬塞进 Redis，只会让单线程更脆弱。
