触发器内查配置表慢是因为每次DML都执行完整SQL流程，且无法缓存或异步加载；应移至应用层初始化或用会话变量预加载，避免重复查询。
触发器里直接查配置表为什么慢
因为每次 INSERT/UPDATE/DELETE 触发时，SELECT 都走完整查询流程：解析、优化、执行、返回结果。配置表哪怕只有几行，也会触发磁盘 I/O（尤其没建索引或缓存未命中时），在高并发写入场景下，延迟会明显放大。
更麻烦的是，MySQL 的 BEFORE 触发器里不能用事务控制语句（如 START TRANSACTION），也不能调用存储函数以外的复杂逻辑，所以没法在触发器内做连接池或异步加载。
- 配置表无主键或未对
key_name建唯一索引 → 每次查都全表扫描 - 触发器中写
SELECT @config_val := value FROM config_table WHERE key_name = 'timeout'→ 变量作用域仅限当前语句，下次触发就失效 - 多个触发器同时读同一配置 → 无共享缓存，重复查表
用 MySQL 用户变量 + 初始化脚本模拟“缓存”
MySQL 5.7+ 支持会话级用户变量，虽不能跨会话共享，但能避免单次触发内多次查表。关键是要在连接建立后、业务操作前一次性加载，而不是在每个触发器里重复查。
实操上，把配置加载逻辑从触发器里移出来，放到应用层连接初始化阶段（比如 ORM 的 connection pool setup hook），或者用 init_connect 配置项自动执行：
SET GLOBAL init_connect = "SELECT @cfg_timeout := value FROM config_table WHERE key_name = 'timeout'; SELECT @cfg_retry := value FROM config_table WHERE key_name = 'retry_count';";
然后触发器里直接用：
IF NEW.status = 'pending' AND NEW.retry_count < @cfg_retry THEN SET NEW.timeout_at = DATE_ADD(NOW(), INTERVAL @cfg_timeout SECOND); END IF;
-
@cfg_timeout必须在触发器执行前已赋值，否则为NULL，导致条件判断失败 - 用户变量不支持跨会话，换连接就得重载；不适合配置频繁变更的场景
- 不能用
DECLARE在触发器里声明变量并赋值（语法错误），只能依赖外部注入
触发器中调用存储函数封装配置读取逻辑
把配置查询逻辑封装成 DETERMINISTIC 函数，虽然仍会查表，但至少统一了调用方式，便于后续替换为缓存版本。
定义函数示例（注意加 SQL SECURITY DEFINER，避免权限问题）：
DELIMITER $$ CREATE FUNCTION get_config_value(p_key VARCHAR(64)) RETURNS VARCHAR(255) READS SQL DATA DETERMINISTIC SQL SECURITY DEFINER BEGIN DECLARE v_val VARCHAR(255) DEFAULT NULL; SELECT value INTO v_val FROM config_table WHERE key_name = p_key LIMIT 1; RETURN v_val; END$$ DELIMITER ;
触发器中调用：
SET @timeout_sec = CAST(get_config_value('timeout') AS UNSIGNED);
- 函数必须标
READS SQL DATA，否则触发器里不允许调用 - 别在函数里做复杂逻辑（比如 fallback 到默认值），触发器里无法捕获异常，出错直接中断操作
- 如果配置表有更新，函数不会自动感知，仍需手动刷新或靠应用层兜底
真正需要缓存时，别硬扛在触发器里
触发器本质是数据库的“钩子”，不是运行环境。想实现配置热更新、多节点同步、TTL 控制，就得让出控制权——把配置读取移到应用层，通过参数传入 SQL 或使用动态生成的触发器逻辑（如用 PREPARE + EXECUTE，但 MySQL 触发器中禁止该操作）。
可行折中方案：应用在启动时加载配置到内存，写入时显式带参，比如：
INSERT INTO orders (...) VALUES (...), (@cfg_timeout, @cfg_retry);
再让触发器读这些传入的用户变量。这样既避开查表，又保留灵活性。
最常被忽略的一点：很多人试图在触发器里用 SELECT ... INTO OUTFILE 或调用 SYS_EVAL（已废弃）绕过限制，结果不是报错就是引入安全漏洞。触发器的边界很清晰——它只适合轻量、确定、无副作用的数据校验和补全。
