.htaccess 中的 1218 重定向指令不应导致明显/显着延迟，但是您的建议还有其他问题，可以对此进行极大优化以避免任何额外开销...
...必须在每次页面加载时查询其中的每一个？
不仅仅是“每个页面加载”，还可能是每个请求。所有静态资源（CSS、JS、图像等）都将触发同一组指令（除非它们托管在远离应用服务器的地方）。
RewriteEngine on
Redirect 301 https://digimoncard.io/deck/?deckid=1241 https://digimoncard.io/deck/green-otk-1241
这行不通。 mod_alias Redirect 指令仅匹配 URL 路径，它不匹配查询字符串（或方案+主机名），因此上述指令将无法匹配并且什么也不做。 （RewriteEngine 也是 mod_rewrite 的一部分，而不是 mod_alias。）
为了匹配查询字符串，您需要使用带有附加 条件 的 mod_rewrite 来检查 QUERY_STRING 服务器变量。例如：
RewriteCond %{QUERY_STRING} ^deckid=(1241)$
RewriteRule ^deck/$ /green-otk-%1 [R=301,L]
%1 反向引用包含 1241（从前面的 CondPattern 中捕获）——这只是节省了重复（这可能会引入错误）。当然，除非您自动生成这些指令。
不要使用.htaccess - 请改用您的应用程序逻辑
但是，理想情况下，您一开始就不会在 .htaccess 中进行这些重定向。在您的应用程序逻辑中执行这些操作会更加优化（理想情况下，当您的站点确定结果会触发 404 时 - 尽管在您的情况下不会发生这种情况）。通过将这些指令放在.htaccess 中，您会优先考虑“重定向”，但会牺牲正常的网站流量。通过稍后（在您的应用程序中）实施这些重定向，您可以优先考虑正常的网站流量。
因为我假设您正在使用前端控制器来路由您的 URL，所以这应该相对容易实现。 （只有当请求与旧 URL 格式匹配时，您才处理重定向逻辑。）
优化 .htaccess 版本
但是，如果您决定使用 .htaccess 路由，如果您的所有旧 URL 都遵循相同的格式，那么您可以大大优化这一点……您可以在内部将任何使用格式 /deck/?deckid=<number> 的请求重写到子目录（假设所有您的旧网址使用这种格式）。然后，您在处理所有 1218 重定向的子目录中有另一个 .htaccess 文件。这样，您的主 .htaccess 文件中只有一个指令，该指令在每个请求上都进行处理，并且仅在需要时才处理重定向逻辑（在子目录 .htaccess 文件中）。
这避免了在主 .htaccess 文件中包含 1000 多个重定向指令的开销。
子目录.htaccess文件中的指令也可以简化，因为我们可以重写将查询字符串移动到URL路径的请求，以避免以后额外的条件。
例如，在您的根 .htaccess 文件的顶部：
RewriteEngine On
# Internally rewrite the request for (what looks like) an old URL
# ...to the "/redirect-old" subdirectory
RewriteCond %{QUERY_STRING} ^deckid=(\d+)$
RewriteRule ^deck/$ redirect-old/%1 [L]
/deck/?deckid=<number> 形式的所有 URL 在内部被重写为 /redirect-old/<number>...
然后，在/redirect-old/.htaccess 中，您有简化“重定向”指令，如下所示，与 重写 URL 相匹配：
# /redirect-old/.htaccess
RewriteEngine On
# Redirect old URLs
RewriteRule ^1241$ /deck/green-otk-$0 [R=301,L]
RewriteRule ^1234$ /deck/foo-$0 [R=301,L]
RewriteRule ^4321$ /deck/bar-$0 [R=301,L]
:
这些指令匹配重写的 URL，即。 /redirect-old/<number> 并相应地重定向。
每种情况下的$0 反向引用只是与RewriteRule 模式 匹配的URL 路径（即数字）。 （节省重复 - 如上所述。）