Redis Lua脚本编程：提升原子性操作与性能的秘密武器

DemonAvenger2025-12-24 11:24

1. 引言

想象一下，你正在开发一个电商系统，促销活动刚一上线，库存却因为并发请求瞬间变成了负数；或者你在优化一个实时排行榜，频繁的Redis命令调用让网络开销拖慢了整个服务。这些问题听起来是不是有点耳熟？你可能已经熟练掌握了Redis的基础操作，比如SET、GET、INCR，甚至用过MULTI/EXEC来保证事务性，但面对高并发和复杂逻辑时，总感觉还差了点"火候"。别急，今天我们要聊的Redis Lua脚本编程，或许就是你一直在寻找的那把"秘密武器"。

Redis Lua脚本是一种内置于Redis的高级功能，通过EVAL命令调用Lua解释器，让你可以在服务端执行自定义逻辑。它不仅能保证操作的原子性，还能大幅减少网络往返开销，从而提升性能。简单来说，它就像一个"魔法盒子"，把多条命令打包成一个原子操作，既安全又高效。对于那些已经有1-2年Redis使用经验、希望更进一步的开发者来说，Lua脚本无疑是值得深入探索的宝藏。

这篇文章的目标很明确：带你从入门到实战，揭示Redis Lua脚本的核心优势，并结合我在实际项目中的经验，分享一些踩坑教训和解决方案。我们会从基础知识讲起，逐步剖析它的原子性和性能优势，再通过几个典型场景展示它的威力，最后总结一些实用建议。无论你是想解决并发竞争问题，还是希望优化系统性能，这篇文章都会给你一些启发。准备好了吗？让我们一起打开Redis Lua脚本的"魔法书"，看看它到底能为我们带来什么惊喜！

过渡到下一节：在正式进入实战之前，我们先从基础打起。接下来，我会带你快速了解Redis Lua脚本是什么，它和传统操作有何不同，以及如何用一个简单示例上手。别担心，即使你没接触过Lua语言，也能轻松跟上节奏。

2. Redis Lua脚本入门

从引言中我们已经知道，Redis Lua脚本是个能解决并发和性能问题的"魔法盒子"。但具体来说，它是什么？怎么用？为什么值得我们花时间去学习？这一节，我们将从零开始，带你快速入门Redis Lua脚本编程。即使你对Lua语言一无所知，也能在几分钟内上手一个简单的脚本。

什么是Redis Lua脚本？

Redis从2.6版本开始内置了Lua 5.1解释器，通过EVAL命令允许用户在服务端执行自定义脚本。简单来说，它就像在Redis内部嵌了一个小型编程环境，你可以用Lua语言写逻辑，直接操作Redis的键值数据。传统的Redis操作通常是客户端发送一条条命令，比如GET、SET，而Lua脚本则是把多条命令打包成一个脚本，一次性交给Redis执行。

与Redis的事务（如MULTI/EXEC）相比，Lua脚本有明显的不同。MULTI/EXEC虽然也能组合多条命令，但本质上是客户端驱动的事务，需要多次网络交互，而且在高并发下容易因乐观锁失败而重试。而Lua脚本是服务端原子执行的，执行过程不会被打断，天然适合并发场景。

为什么要用Lua脚本？

用Lua脚本主要有两大驱动力：原子性 和性能。

  • 原子性 ：想象你在扣减库存，如果用普通命令，先GET检查库存，再DECR扣减，这中间如果有并发请求插进来，就可能导致超卖。而Lua脚本把逻辑封装成一个整体，一次执行，避免了这种竞争。
  • 性能：每次客户端与Redis通信都有网络开销（RTT，Round-Trip Time）。如果一个业务需要10条命令，传统方式要10次往返，而Lua脚本只需要1次，效率提升显而易见。

为了直观对比，我们可以用一个表格来总结：

特性 传统命令（MULTI/EXEC） Lua脚本
执行方式 客户端分步发送 服务端一次性执行
原子性 依赖乐观锁，易失败重试 天然原子，无中断
网络开销 多次RTT 单次RTT
逻辑复杂度 简单命令组合 支持复杂逻辑（如循环）
快速上手示例

让我们通过一个简单的计数器示例，实际感受一下Lua脚本的魅力。需求是：实现一个带上限的计数器，每次调用加1，但不能超过指定限制。

lua 复制代码 
-- 带上限的计数器脚本
-- KEYS[1]: 计数器的键名
-- ARGV[1]: 上限值
local key = KEYS[1]              -- 从KEYS数组获取键名
local limit = tonumber(ARGV[1])  -- 从ARGV获取上限并转为数字
local current = tonumber(redis.call('GET', key) or 0)  -- 获取当前值，默认0
if current < limit then          -- 判断是否未达上限
    redis.call('INCR', key)      -- 未达上限则加1
    return 1                     -- 返回成功
else
    return 0                     -- 已达上限，返回失败
end

调用方式：

bash 复制代码 
redis-cli EVAL "script content" 1 mycounter 10
  • 1表示1个KEY，mycounter是键名，10是上限。
  • 返回1表示成功加1，返回0表示已达上限。

代码解析：

  1. KEYS和ARGV是脚本的两个输入参数，分别存储键名和额外参数，数组从1开始索引。
  2. redis.call()是调用Redis命令的接口，比如redis.call('GET', key)等价于客户端的GET key。
  3. tonumber()确保数值类型安全，避免字符串导致逻辑错误。
  4. 返回值会传回客户端，方便判断结果。

这个例子展示了Lua脚本的基本结构：输入参数、Redis操作、逻辑判断和返回值。是不是比你想象的简单？

过渡到下一节：通过这个小例子，我们已经迈出了Lua脚本的第一步。但这只是开胃菜，Lua脚本真正的威力在于解决更复杂的并发和性能问题。接下来，我们将深入探讨它的核心优势，看看它如何在库存扣减、性能优化等场景中大显身手。

3. Lua脚本的核心优势

上一节我们通过一个简单的计数器示例，初步感受了Redis Lua脚本的便捷性。但如果仅仅停留在"简单好用"的层面，那就太小看它的潜力了。在实际项目中，Lua脚本之所以被称为"秘密武器"，是因为它在原子性保障 、性能优化 和灵活性上的表现堪称惊艳。这一节，我们将逐一拆解这三大优势，结合代码和案例，带你看看它如何在复杂场景中化繁为简。

原子性保障

在高并发场景下，数据一致性是个老大难问题。比如电商系统中的库存扣减，如果用传统方式，先GET检查库存，再用SET或DECR更新，中间的空隙很容易被其他请求"钻空子"，导致超卖。Redis提供了WATCH/MULTI/EXEC来实现乐观锁，但这种方式在并发压力大时，失败重试的概率会飙升，性能反而下降。

Lua脚本的杀手锏在于服务端原子执行。整个脚本作为一个整体运行，不会被其他命令打断，彻底杜绝了竞争条件。来看一个库存扣减的例子：

lua 复制代码 
-- 库存扣减脚本
-- KEYS[1]: 库存键名
-- ARGV[1]: 扣减数量
local stock_key = KEYS[1]              -- 获取库存键
local quantity = tonumber(ARGV[1])     -- 获取扣减数量
local stock = tonumber(redis.call('GET', stock_key) or 0)  -- 获取当前库存，默认0
if stock >= quantity then              -- 检查库存是否足够
    redis.call('DECRBY', stock_key, quantity)  -- 扣减库存
    return 1                           -- 返回成功
else
    return 0                           -- 库存不足，返回失败
end

调用方式：

bash 复制代码 
redis-cli EVAL "script content" 1 product:stock 5
  • product:stock是库存键，5是要扣减的数量。
  • 返回1表示扣减成功，0表示库存不足。

与传统方式对比：

  • WATCH/MULTI/EXEC ：需要客户端多次交互，先WATCH监控键，再GET检查，最后MULTI/EXEC提交。如果期间键被修改，事务失败，需要重试。
  • Lua脚本：一次调用，服务端完成所有逻辑，无需重试，原子性有保障。

我在一个电商项目中就遇到过超卖问题。当时用WATCH方案，峰值时重试率高达30%，QPS直接腰斩。改用Lua脚本后，问题迎刃而解，成功率接近100%。

示意图：

rust 复制代码 
传统方式：    客户端 -> GET -> 检查 -> SET -> Redis（可能失败）
Lua脚本：     客户端 -> EVAL（检查+扣减） -> Redis（原子执行）
性能优化

除了原子性，Lua脚本还能显著提升性能。每次客户端与Redis通信都有网络往返开销（RTT），尤其在高频操作中，这部分延迟会累积成性能瓶颈。Pipeline（管道）可以批量发送命令减少RTT，但它只是"打包发送"，执行仍是逐条进行，无法保证原子性。而Lua脚本不仅减少了RTT，还在服务端高效执行。

以下是Pipeline和Lua脚本的对比：

方式 RTT次数 原子性 执行效率
单条命令 N次 无 低
Pipeline 1次 无 中
Lua脚本 1次 有 高（服务端执行）

在一个实时统计项目中，我们需要批量更新10个键的值。使用Pipeline时，QPS在5000左右，改用Lua脚本后，QPS提升到6000，性能提升约20%。原因很简单：Lua脚本把逻辑交给Redis内部的C实现，省去了客户端的解析和多次通信。

灵活性

Lua脚本的另一个亮点是它的灵活性。传统Redis命令是"死板"的，只能按固定方式组合，而Lua脚本支持条件判断、循环甚至简单的计算，堪称Redis的"编程扩展包"。比如，我们可以用它实现批量操作的动态处理：

lua 复制代码 
-- 批量增加多个键的值
-- KEYS: 键名列表
-- ARGV[1]: 增量
for i, key in ipairs(KEYS) do          -- 遍历所有键
    local current = tonumber(redis.call('GET', key) or 0)
    redis.call('SET', key, current + tonumber(ARGV[1]))  -- 增加指定值
end
return #KEYS                           -- 返回处理的键数量

调用方式：

bash 复制代码 
redis-cli EVAL "script content" 3 key1 key2 key3 10
  • 处理key1、key2、key3，每个值加10。

这个脚本展示了循环和动态操作的能力，远超Pipeline的简单批量提交。

过渡到下一节：通过原子性、性能和灵活性三大优势，我们已经看到了Lua脚本的强大之处。但光说不练可不行，接下来我们将走进实际项目，看看它在分布式锁、业务逻辑封装等场景中如何大展拳脚，同时分享一些真实的踩坑经验。

4. 实际项目中的应用场景

上一节我们剖析了Lua脚本的三大核心优势：原子性、性能和灵活性。这些特质听起来很美，但真正让它发光发热的，还是在实际项目中的落地应用。这一节，我将带你走进三个典型场景，看看Lua脚本如何解决分布式锁、复杂业务逻辑和热点数据更新的难题，同时分享一些我在项目中踩过的坑和解决思路。

场景1：分布式锁的高效实现

在分布式系统中，锁是确保资源互斥访问的常见手段。Redis的分布式锁通常用SETNX（Set if Not Exists）实现加锁，用EXPIRE设置超时释放。但如果分开执行这两步，服务器宕机可能导致锁无法释放。Lua脚本可以把加锁和设置超时封装成一个原子操作，避免这种风险。

lua 复制代码 
-- 分布式锁加锁脚本
-- KEYS[1]: 锁的键名
-- ARGV[1]: 锁的唯一值（用于释放时验证）
-- ARGV[2]: 超时时间（毫秒）
local lock_key = KEYS[1]
local lock_value = ARGV[1]
local ttl = ARGV[2]
if redis.call('SETNX', lock_key, lock_value) == 1 then  -- 尝试加锁
    redis.call('PEXPIRE', lock_key, ttl)                -- 设置超时
    return 1                                            -- 加锁成功
else
    return 0                                            -- 加锁失败
end

调用方式：

bash 复制代码 
redis-cli EVAL "script content" 1 mylock 12345 10000
  • mylock是锁键，12345是唯一值，10000是10秒超时。
  • 返回1表示加锁成功，0表示已被占用。

释放锁脚本（简单示例）：

lua 复制代码 
if redis.call('GET', KEYS[1]) == ARGV[1] then  -- 验证锁归属
    redis.call('DEL', KEYS[1])                 -- 释放锁
    return 1
else
    return 0                                   -- 非本人锁，无权释放
end

优点：

  • 原子性确保加锁和超时设置不被打断，避免了"锁死"风险。
  • 比客户端分步操作更高效，减少了一次RTT。

项目经验 ：在一个支付系统中，我们用Lua脚本实现了分布式锁，保证订单处理的互斥性。相比传统的SETNX+EXPIRE，宕机场景下的锁残留问题完全消失。

场景2：复杂业务逻辑的封装

有些业务逻辑涉及多个步骤，比如电商订单处理：检查库存、扣减库存、记录日志。如果用客户端分步调用，不仅效率低，还可能因网络抖动导致部分步骤失败。Lua脚本可以将这些步骤封装成一个原子操作。

lua 复制代码 
-- 订单处理脚本
-- KEYS[1]: 库存键
-- KEYS[2]: 日志键
-- ARGV[1]: 扣减数量
-- ARGV[2]: 日志内容
local stock_key = KEYS[1]
local log_key = KEYS[2]
local quantity = tonumber(ARGV[1])
local log_msg = ARGV[2]
local stock = tonumber(redis.call('GET', stock_key) or 0)
if stock >= quantity then
    redis.call('DECRBY', stock_key, quantity)         -- 扣减库存
    redis.call('RPUSH', log_key, log_msg)             -- 记录日志
    return 1                                          -- 成功
else
    return 0                                          -- 库存不足
end

调用方式：

bash 复制代码 
redis-cli EVAL "script content" 2 product:stock order:log 5 "order123 processed"

优点：

  • 多步骤逻辑原子执行，避免中间状态不一致。
  • 服务端处理减少了客户端的协调成本。

项目经验：在一个秒杀活动中，我们用类似脚本处理订单，单节点QPS从3000提升到4500，客户端代码也简化了不少。

场景3：热点数据批量更新

实时排行榜是Redis的经典应用场景，比如游戏积分榜。每次更新可能涉及多个用户的数据，传统方式需要逐条调用ZINCRBY，网络开销大且效率低。Lua脚本可以批量处理，动态更新热点数据。

lua 复制代码 
-- 批量更新排行榜
-- KEYS: 用户ID列表
-- ARGV: 对应的积分增量列表
local updates = {}
for i, key in ipairs(KEYS) do
    local score = tonumber(ARGV[i])
    redis.call('ZINCRBY', 'leaderboard', score, key)  -- 更新积分
    updates[i] = redis.call('ZSCORE', 'leaderboard', key)  -- 获取最新积分
end
return updates  -- 返回所有用户的最新积分

调用方式：

bash 复制代码 
redis-cli EVAL "script content" 3 user1 user2 user3 10 20 5

踩坑经验：

  • 问题 ：早期版本脚本太长（循环处理100个用户），执行时间超出了默认的lua-time-limit（5秒），导致Redis阻塞。
  • 解决：将批量更新拆成小批次（每次10-20个），并优化逻辑减少计算量，最终稳定运行。

示意图：

rust 复制代码 
传统方式：    客户端 -> ZINCRBY user1 -> ZINCRBY user2 -> ... -> Redis
Lua脚本：     客户端 -> EVAL（批量更新） -> Redis

项目经验：在一个游戏排行榜中，改用Lua脚本后，更新延迟从50ms降到10ms，用户体验显著提升。

过渡到下一节：通过这三个场景，我们看到了Lua脚本在实战中的威力。但要用好它，还需要一些技巧和注意事项。下一节，我将分享最佳实践和踩坑经验，帮你在项目中少走弯路。

5. 最佳实践与踩坑经验

通过前面的场景分析，我们已经见识了Lua脚本在分布式锁、业务逻辑封装和热点数据更新中的强大能力。但就像任何利器一样，用得好能事半功倍，用不好可能会"伤到自己"。这一节，我将结合实际项目经验，分享一些最佳实践和踩过的坑，帮你在使用Lua脚本时少走弯路，充分发挥它的潜力。

最佳实践

要让Lua脚本成为你的得力助手，以下几点值得铭记：

  1. 脚本短小精悍

    Lua脚本运行在Redis服务端，执行时间直接影响Redis的响应能力。尽量避免复杂的计算或过多的循环，把重逻辑交给客户端或后台任务处理。比如，上一节的排行榜更新脚本，我们限制了每次处理的键数量，避免阻塞。

  2. 使用EVALSHA减少传输开销
    EVAL每次都需要传输完整脚本，网络开销较大。更好的方式是用SCRIPT LOAD预加载脚本，返回SHA1哈希值，然后用EVALSHA调用。
    示例：

    bash 复制代码 
    redis-cli SCRIPT LOAD "return redis.call('GET', KEYS[1])"
# 返回SHA1: "a42059b356c875f0712db19a51f6aaca403f8265"
redis-cli EVALSHA a42059b356c875f0712db19a51f6aaca403f8265 1 mykey

    优点：减少带宽占用，尤其适合频繁调用的脚本。

  3. 参数化设计

    通过KEYS和ARGV动态传入参数，而不是硬编码键名或值。这样脚本更通用，可复用性强。比如库存扣减脚本中，键名和数量都通过参数传入，避免为每个商品写一个脚本。

  4. 调试技巧：借助redis.log

    Lua脚本不像客户端代码那样容易调试，可以用redis.call('LOG', level, message)记录中间状态。
    示例：

    lua 复制代码 
    redis.call('LOG', 'NOTICE', 'Current stock: ' .. stock)

    输出到Redis日志，方便排查问题。

最佳实践速览表：

实践点 建议 收益
脚本长度 短小精悍，避免复杂计算 降低阻塞风险
调用方式 EVALSHA代替EVAL 减少网络开销
参数设计 KEYS/ARGV动态传入 提高复用性
调试手段 redis.log记录中间状态 加速问题定位
踩坑经验

实践出真知，也出"坑"。以下是我在项目中遇到的一些典型问题和解决方案：

  1. 坑1：脚本执行超时导致Redis阻塞
    场景 ：一个批量更新脚本处理100个键，包含循环和条件判断，执行时间超出了默认的lua-time-limit（5秒），Redis直接报BUSY错误，客户端请求堆积。
    解决：

    • 优化脚本逻辑，减少不必要的操作。
    • 将大任务拆成小批次处理。
    • 调整Redis配置lua-time-limit，但需谨慎评估影响。
      经验：脚本执行时间尽量控制在毫秒级，避免影响主线程。

  2. 坑2：KEYS和ARGV使用不当引发错误
    场景 ：一个脚本忘了用tonumber()转换ARGV，传入字符串"10"时，比较逻辑失效，导致库存扣减异常。
    解决：

    • 对所有数值参数加tonumber()，如tonumber(ARGV[1]) or 0。
    • 在客户端严格校验输入类型，避免传非法值。
      经验：Lua是动态类型语言，类型安全要自己把关。

  3. 坑3：集群模式下的兼容性问题
    场景 ：在Redis Cluster中，一个脚本操作了多个键，但这些键不在同一个slot，报CROSSSLOT错误。
    解决：

    • 使用hash tag（如{tag}key1、{tag}key2）确保键在同一slot。
    • 设计时尽量减少跨slot操作，或拆分脚本。
      经验：集群环境下，键的分布是关键，提前规划好。
项目经验分享

在一个高并发支付系统中，我们用Lua脚本实现了订单状态检查和库存扣减。起初脚本直接处理所有逻辑，包括日志记录和状态更新，执行时间达到200ms，偶尔触发超时。优化后，我们把非核心逻辑（日志）移到客户端异步处理，脚本只负责原子操作，执行时间降到20ms，QPS从4000提升到6000。这个案例告诉我：Lua脚本的核心价值在于原子性，复杂计算还是交给其他组件更合适。

过渡到下一节：掌握了最佳实践和避坑技巧，你已经离"Lua脚本大师"不远了。但任何技术都有局限性，下一节我们将聊聊Lua脚本的注意事项和潜在风险，确保你在使用时心中有数。

6. 注意事项与局限性

通过前面的学习，我们已经掌握了Lua脚本的强大功能和使用技巧。但再厉害的"秘密武器"也有自己的边界。这一节，我们将聊聊Redis Lua脚本的局限性、潜在风险以及如何在实践中妥善应对，确保你用得安心、用得顺手。

脚本的局限性

Lua脚本虽然灵活，却不是万能的，以下几点需要特别注意：

  • 不支持复杂IO操作
    Redis的Lua解释器只支持与Redis本身的交互，无法直接访问文件、网络或外部数据库。比如，你不能在脚本中调用HTTP接口获取数据。这种限制让它更像一个"轻量级执行器"，适合简单逻辑而非复杂任务。
  • 集群模式下的slot限制
    在Redis Cluster中，所有KEYS必须位于同一个slot，否则会报CROSSSLOT错误。虽然可以用hash tag（如{tag}key）解决，但这增加了设计复杂度。如果业务需要频繁操作跨slot键，可能得考虑其他方案，比如客户端分片逻辑。

局限性速览表：

局限性 描述 应对建议
IO限制 仅支持Redis命令，无外部交互 将IO逻辑放客户端处理
集群slot限制 KEYS需在同一slot 使用hash tag或拆分操作
安全性

Lua脚本虽小，却可能藏着安全隐患：

  • 防止脚本注入
    如果脚本直接拼接用户输入（比如把ARGV拼接到命令中），可能被恶意用户注入危险代码。虽然Redis的Lua沙箱限制了系统调用，但拼接不当仍可能导致逻辑错误或数据泄露。
    错误示例 ：

    lua 复制代码 
    redis.call('SET', KEYS[1], ARGV[1] .. ' malicious code')

    正确做法 ：避免拼接，严格使用KEYS和ARGV作为参数，客户端提前校验输入。

经验 ：我在一个项目中见过因未校验ARGV导致的异常，客户端传入空字符串，脚本逻辑直接崩溃。从那以后，我们强制在客户端加了参数过滤。

监控与维护

用得好Lua脚本，还要管得好：

  • 执行时间监控
    脚本执行时间过长会阻塞Redis主线程，影响其他请求。可以通过Redis的SLOWLOG命令查看慢脚本（SLOWLOG GET），或者用redis-cli --stat观察总体性能。
  • 错误排查
    脚本出错时，Redis会返回错误信息（如ERR script timeout），但具体原因需要结合日志分析。建议在开发时用redis.log记录关键变量，生产环境中搭配外部监控工具（如Prometheus）跟踪脚本调用情况。

注意事项：一个真实的教训是，我们曾因未监控脚本执行时间，线上突发流量时Redis响应延迟暴增。后来加了慢日志告警，问题定位时间从小时级降到分钟级。

过渡到下一节：了解了Lua脚本的局限性和注意事项，你已经具备了全面驾驭它的能力。最后一节，我们将总结全文，提炼实践建议，并展望它的未来发展。

7. 结尾

经过前六节的探索，我们从Redis Lua脚本的基础入门，到核心优势、实战场景，再到最佳实践和注意事项，完整地走了一遍它的"成长之路"。现在，是时候停下来回顾一下，这把"秘密武器"究竟给我们带来了什么，以及如何在未来的项目中用好它。

总结

Redis Lua脚本之所以强大，核心在于它的原子性 和性能优化。它像一个高效的"事务管家"，把复杂的多命令操作封装成一次服务端执行，避免了并发竞争；又像一个"网络加速器"，减少了客户端与Redis之间的频繁通信。在分布式锁、业务逻辑封装和热点数据更新等场景中，它展现了无与伦比的优势。我在多个项目中见证了它将QPS提升20%-50%的表现，也体会到它简化代码带来的开发效率提升。对于高并发、复杂逻辑的场景，Lua脚本无疑是一个值得信赖的伙伴。

实践建议

想用好Lua脚本，不妨从这几步开始：

  1. 从小处着手 ：找一个简单的场景（比如计数器或锁）试试手，熟悉KEYS、ARGV和redis.call。
  2. 优化为王 ：保持脚本精简，用EVALSHA减少开销，监控执行时间避免阻塞。
  3. 团队协作：把常用的脚本整理成库，结合hash tag支持集群，确保可维护性。
未来展望与心得

从技术生态看，Lua脚本与Redis的结合只是开始。随着微服务和云原生的普及，Redis可能会进一步增强脚本功能，比如支持更复杂的逻辑或与外部系统集成。未来，我们或许能看到更智能的脚本调试工具，甚至是AI辅助生成脚本的可能性。作为一名开发者，我在使用Lua脚本的过程中，不仅解决了技术难题，还体会到"少即是多"的设计哲学------用最少的代码，实现最大的价值。

鼓励与互动

如果你还没在项目中尝试过Lua脚本，不妨从今天开始动手实践。它可能不会立刻解决所有问题，但一定会让你的技术深度更进一步。有什么使用心得或疑问吗？欢迎在评论区留言，我们一起探讨如何让这把"秘密武器"发挥更大威力！

相关推荐
你住过的屋檐6 小时前
【oracle】oracle数据处理将一行数据根据条件拆分为多行
数据库·oracle
Channing Lewis6 小时前
数据库的dump备份
数据库
开开心心_Every6 小时前
无广告干扰：简单好用文字LOGO设计工具
xml·java·网络·数据库·华为od·华为云·excel
悄悄敲敲敲6 小时前
数据库：库的操作
数据库
JAVA学习通6 小时前
数据库备份与恢复（2）
数据库
lhrimperial6 小时前
MongoDB核心技术深度解析题
数据库·mongodb
宠..6 小时前
为单选按钮绑定事件
运维·服务器·开发语言·数据库·c++·qt·microsoft
宠..6 小时前
对单选按钮分组
开发语言·数据库·c++·qt·安全·安全性测试
Ashley_Amanda7 小时前
SAP ABAP 开发全攻略：从核心编程到最佳实践
大数据·数据库·sql
热门推荐
01GitHub 镜像站点02UV安装并设置国内源03Linux下V2Ray安装配置指南04从快手“12·22”直播攻击事件看：一次教科书式的业务层饱和攻击05在VSCode配置Java开发环境的保姆级教程（适配各类AI编程IDE）06Gemini3 生成的基于手势控制3D粒子圣诞树07解决 WSL Ubuntu 中 /etc/resolv.conf 自动重置问题08Labelme从安装到标注：零基础完整指南09CentOS的ISO镜像下载10GLM-4.7 vs MiniMax-M2.1：代码工程理解