SQLite触发器从入门到实战：语法、案例与避坑指南

先聊点实际的。我以前刚接触SQLite那会儿，看到“触发器”三个字，第一反应是数字电路里的D触发器、JK触发器，脑子里全是波形图和边沿触发那套东西。后来被同事纠正，才明白SQLite里的触发器完全是另一码事——它是在数据库表上挂的“自动回调函数”。

要说这东西冷门吧，其实每个做客户端开发、嵌入式开发、甚至用Python写小工具的人，早晚都得撞上它。最常见的一个需求：业务表里每条记录的“最后更新时间”字段，每次UPDATE都要手动带上当前时间戳，写得多了就烦，漏写一次数据就脏了。再比如给用户表做操作审计，谁在什么时候改了哪个字段，如果全靠业务代码里挨个埋点，代码库能脏成什么样，想想都知道。SQLite触发器就是干这个的，它能在INSERT、UPDATE、DELETE发生时自动执行一段预定义的SQL逻辑，不需要你改一行业务代码。

这篇文章，我就把SQLite触发器的设计思路、语法细节、实操案例、以及我实际踩过的坑一次性讲透。适合用它做本地存储的客户端开发者、刚入手SQLite的初学者。我会从最简单的场景讲起，一直讲到一个相对完善的生产级触发器方案，尽量把每个“为什么这么做”都交代清楚。

1. 先把概念拧清楚：SQLite触发器到底是什么

1.1 它不是数字电路里的触发器

搜“SQLite触发器”的时候，很多人会连带搜到“D触发器”“JK触发器”“RS触发器工作原理”。这是两套完全同名的东西，但毫无关系。数字电路里的触发器是存储电路元件，靠着时钟边沿保存一位数据；SQLite里的触发器，可以理解成一张表上的“哨兵”——当指定的数据变更操作发生，哨兵就去执行一段你提前写好的SQL。

为什么搜SQLite的人会搜到数字电路的东西呢？我猜测是很多入门者一开始没搞明白这两者的区别，在搜索引擎里反反复复试关键词，结果被带偏了。这里就直接说结论：如果你的目标是学数据库触发器，看到时序图、波形图、真值表之类的内容，直接关掉，那跟你要做的事情没关系。

SQLite的触发器属于“行级触发器”，它在数据行的操作层面生效，每处理一行数据就会触发一次。逻辑上它做得非常像现代编程语言里的“事件监听器”——但比事件监听器更底层，它是数据库引擎自己执行的，不受应用层是否调用、是否忘记调用的影响，天然具备“不可绕过”的属性。这对于维护数据一致性来说，价值非常大。

1.2 SQLite触发器的三类触发时机

SQLite支持三类触发时机，分别是BEFORE、AFTER和INSTEAD OF。每一个都对应着不同的执行阶段。

BEFORE触发器在数据变更动作真正执行之前运行。如果你在BEFORE触发器里用RAISE(ABORT)抛出异常，这个数据变更会被整体取消。比较典型的用法是复杂校验、加密字段值、给字段设定默认值——这些操作必须在数据真正落盘前完成。

AFTER触发器在数据变更动作完成之后运行。它不会影响已经被修改的数据行（因为数据已经变了），适合做审计日志、同步更新冗余表、清理关联数据。我用它做得最多的就是操作审计。

INSTEAD OF触发器比较特殊，它只适用于视图（VIEW）。SQLite里的视图默认是不可写的，但你可以给视图创建INSTEAD OF触发器，在应用层看起来是对视图做INSERT/UPDATE，实际上由触发器把操作分散到真正的基础表上。这对那些有复杂JOIN视图更新需求的业务，几乎是标准解法。

触发粒度方面，SQLite只有FOR EACH ROW，不支持FOR EACH STATEMENT。也就是说，一条UPDATE语句如果影响了100行，这个触发器就会被执行100次。这个特性有好有坏：好处是每行数据都能用NEW和OLD分别拿到当前行和旧行的值，逻辑可以写得非常细；坏处是如果你在大量数据上做批量操作，触发器的执行开销会被放大，后面我会给一个性能优化思路。

1.3 触发器的“新旧行”概念

这是SQLite触发器最核心、也最容易搞混的概念。

在触发器内部，SQLite向用户暴露了四个特殊变量：

举个例子。假设你有一张用户表users，字段有id、name、credit。你想记录积分credit的每次变动，那么在UPDATE触发器里，OLD.credit就是变动前的积分，NEW.credit就是变动后的积分，两者之差就是本次变动幅度。你这个审计功能甚至不需要业务侧提供任何额外参数，完全由数据库自动推导。

需要特别注意的是，在BEFORE INSERT触发器里，NEW.列名是可以被赋值的。这意味着你可以在数据真正插入前，改写某个字段的内容。比如一个字段要求必须小写存储，但业务侧漏做了lower处理，BEFORE INSERT触发器可以直接SET NEW.name = LOWER(NEW.name)，把“保险丝”放在最靠近数据的一环。

但OLD在DELETE触发器里是只读的，你不能通过MODIFY OLD.xxx去修改正在被删除的行的内容，因为它已经没有修改的意义了，你只能“读取”它然后决定做什么，比如把它复制到另一张历史表里。

注意，所有引用到OLD/NEW的赋值都要求目标列是实际存在的，如果拼错了列名，SQLite不会在第1行报错，而是在触发器执行到那一行的时候才给你报错。这类错误隐蔽性很高，所以后面我会强烈建议你在写完每一个触发器后至少做一次完整触发链路的联调，而不是只看建表是否成功。

2. 核心语法拆解与设计思路

2.1 CREATE TRIGGER 标准语法

创建一个触发器，SQLite的语法整体长这样：

sql复制CREATE [TEMP | TEMPORARY] TRIGGER [IF NOT EXISTS] 触发器名
[BEFORE | AFTER | INSTEAD OF] [INSERT | DELETE | UPDATE [OF 列名列表]]
ON 表名
[FOR EACH ROW]
[WHEN 条件表达式]
BEGIN
    -- 触发器要执行的SQL逻辑
END;

方括号里的都是可选内容。这里逐项解释容易显得干巴，我先重点说几个容易忽略的语法细节。

第一个是UPDATE OF 列名列表。如果你写的是UPDATE OF credit，那么这个触发器只在UPDATE语句明确涉及到credit列时才会触发。如果业务侧执行的是UPDATE users SET name = 'x'，credit列没有被牵涉，触发器就不触发。这个细粒度控制在审计场景中非常好用，能减少大量无意义的日志记录。

第二个是WHEN条件。WHEN可以理解成触发器内部的“短路开关”，它会在触发器逻辑执行前先判断一个布尔表达式，只有表达式为真才继续执行。比如你只想记录那些积分变化超过100的操作，就可以写WHEN ABS(NEW.credit - OLD.credit) >= 100，小于100的变更直接被SQLite跳过，连审计日志都不会生成。

第三个是触发器的“执行体”不是只能写一条SQL。在BEGIN...END块里，你可以写多个SQL语句，用分号分割。它们在一个事务的上下文中执行。这带来的隐含约束是：如果在执行过程中任何一条语句出错，整个操作会回滚，不会有半截脏数据落库。

第四点是IF NOT EXISTS。这个选项在脚本重复执行时特别有用。结合后面要讲的sqlite_master表，能用极少的代码完成触发器的幂等部署，比先查后建稳健得多。

2.2 用RAISE()主动中止或抛异常

RAISE()是触发器内部最特殊的函数，它能主动干预外部事务的执行。语法是：

sql复制RAISE(ABORT, '错误提示信息')

我举一个超级典型的场景：你有一个订单表orders，和一个库存表inventory，业务上要求创建订单时库存不能为负。虽然理论上业务层可以通过SELECT判断之后再做INSERT，但真正的并发场景下，两个请求同时读到库存为1，同时各自下单，可能就超卖了。更稳的做法是：在INSERT触发器中，直接把校验下沉到数据库。

大概的思路是这样——假设在订单表上有一个BEFORE INSERT触发器，在校验逻辑里读当前库存量。如果低于订单需求，直接调用RAISE(ABORT, '库存不足')。这句话一执行，SQLite会立刻终止整个INSERT操作，且已经在这个事务中做的其他更改也会一并回滚。类似这种把并发安全放在数据库层的做法，在本地型数据库里非常实用。

RAISE(ABORT)与RAISE(ROLLBACK)在大多数情况下表现一致，区别不在于表面上“是否取消这条语句”，而在于回滚粒度的实现细节。在使用事务包裹批量操作时，如果你想让当前整个事务回滚，用ROLLBACK；如果只想终止当前语句并允许外层继续处理，就用ABORT。我在实际中大部分用ABORT，因为它更符合“阻止坏数据进入”的意图。

另外还有RAISE(IGNORE)，它会把当前触发器的这个数据变更命令静默跳过，不给外部报错。这个在我做“幂等去重”的时候偶尔用，不过使用场景相对窄，逻辑不够透明，不建议在核心业务上多用。

2.3 DROP TRIGGER 与触发器管理

删除触发器非常直接：

sql复制DROP TRIGGER [IF EXISTS] 触发器名;

SQLite的触发器是全局命名的，不是像MySQL那样依附于某张表（不同表可以有同名的触发器），SQLite中触发器的名字在一个数据库范围内不允许重复。所以命名规范特别重要。我的习惯是用一个清晰的前缀体系：

• trg_表名_操作类型_业务含义，比如trg_users_au_audit。
• 操作类型缩写：ai=AFTER INSERT，au=AFTER UPDATE，ad=AFTER DELETE，bi=BEFORE INSERT，bu=BEFORE UPDATE。
• 如果同时要区分表名，就放在第二个字段。

第一次上手的人容易给触发器起trg_1、trg_2这种名字，过一个月自己都看不懂这个触发器到底在干嘛。命名虽然不直接影响功能，但直接决定后续维护成本，值得认真对待。

2.4 SQLite触发器的能力边界

有一点必须坦白：SQLite的触发器能力很有限，不要拿它跟PostgreSQL或Oracle的PL/pgSQL去比。SQLite触发器内部不支持直接定义本地变量，不支持循环，不支持游标，你能做的就是用一条或若干条SQL语句完成逻辑。看起来限制挺多，但反过来想，这种约束逼着你把触发器写得足够朴素简单，倒也降低了翻车概率。

另外一个容易被忽略的点是递归触发。SQLite默认是禁止递归触发器的，也就是一个表上的触发器如果在执行体中又去更新同一张表，它不会再次触发自己。这是用“状态变量跟踪”实现的，虽然默认禁止了直接递归，但“间接递归”是可能发生的。比如触发器A更新了表B，表B上的触发器又去更新表A，在启用了PRAGMA recursive_triggers的情况下就会形成闭环。

对于绝大多数应用场景，我的建议是：保持递归开关默认关闭。如果确实要靠递归触发器实现某些功能，也一定要加WHEN条件来做终止判断，否则一旦形成递归循环跑起来，排查起来非常痛苦。

3. 几个最典型的实操案例：从零动手写

3.1 案例一：自动维护更新时间的触发器

这是触发器的“Hello World”，也是我认为每个入门者都应该亲手写一遍的案例。

假设有一张商品表product：

sql复制CREATE TABLE product (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    price REAL NOT NULL,
    stock INTEGER NOT NULL DEFAULT 0,
    updated_at TEXT
);

业务逻辑要求：每次UPDATE操作，都自动把updated_at刷新为当前时间。

那么你需要建这样一个BEFORE UPDATE触发器：

sql复制CREATE TRIGGER IF NOT EXISTS trg_product_bu_autotime
BEFORE UPDATE ON product
FOR EACH ROW
BEGIN
    SET NEW.updated_at = datetime('now', 'localtime');
END;

注意，这里我选择了BEFORE而不是AFTER，是因为在AFTER触发器中，实际上“修改数据”的动作已经在磁盘层面完成了，你此时再尝试修改NEW的字段并不会把改动写回去。所以，要在触发器中“改写即将写入的行”，BEFORE是唯一正确的选择。

用BEFORE意味着只要这条UPDATE语句成功，updated_at一定已经被刷新。而不管业务代码里有没有主动去维护这个字段，省心很多。

3.2 案例二：完整审计日志表

更新时间的自动维护只是开胃菜，真正的重头戏是审计日志。

假设我有一张用户积分表user_points：

sql复制CREATE TABLE user_points (
    user_id INTEGER PRIMARY KEY,
    points INTEGER NOT NULL DEFAULT 0,
    updated_at TEXT
);

现在要记录每一次积分变动的痕迹。我先建一张独立的审计表：

sql复制CREATE TABLE points_audit_log (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id INTEGER NOT NULL,
    old_points INTEGER,
    new_points INTEGER,
    change_amount INTEGER,
    change_time TEXT NOT NULL
);

然后用一个AFTER UPDATE触发器把变动的数据写进去：

sql复制CREATE TRIGGER trg_user_points_au_audit
AFTER UPDATE ON user_points
FOR EACH ROW
WHEN OLD.points IS NOT NEW.points
BEGIN
    INSERT INTO points_audit_log (
        user_id,
        old_points,
        new_points,
        change_amount,
        change_time
    ) VALUES (
        NEW.user_id,
        OLD.points,
        NEW.points,
        NEW.points - OLD.points,
        datetime('now', 'localtime')
    );
END;

这里有几个细节值得展开。

WHEN OLD.points IS NOT NEW.points这个条件，把那些UPDATE了但积分值没变化的空操作过滤掉了。SQLite里普通等值判断用=在NULL场景下会返回NULL而不是TRUE或FALSE，所以我用了IS NOT。虽然这里points列大概率不会为NULL，但养成使用IS NOT的好习惯在SQLite里是值得的，能避免一部分比较陷阱。

NEW.user_id、OLD.points、NEW.points三者都拿到了，你完全可以审计出是谁、从多少变成多少、变化量是多少、什么时候变的。这套方案最大的优点，是整个流程里业务代码只做普通的UPDATE而不需要知道审计逻辑的存在，未来如果审计规则变了，只改触发器就行，不用跟着业务代码发版。

3.3 案例三：视图上的INSTEAD OF触发器

假设有两张表，一张是订单主表：

sql复制CREATE TABLE orders (
    order_id INTEGER PRIMARY KEY,
    customer_name TEXT NOT NULL,
    total_amount REAL NOT NULL
);

一张是订单明细表：

sql复制CREATE TABLE order_items (
    item_id INTEGER PRIMARY KEY,
    order_id INTEGER NOT NULL REFERENCES orders(order_id),
    product_name TEXT NOT NULL,
    quantity INTEGER NOT NULL,
    price REAL NOT NULL
);

A表的主从结构清晰，但在业务展示时，经常需要连接两张表取汇总数据。建个视图：

sql复制CREATE VIEW v_order_detail AS
SELECT o.order_id, o.customer_name,
       i.item_id, i.product_name, i.quantity, i.price
FROM orders o
LEFT JOIN order_items i ON o.order_id = i.order_id;

视图本身是不可写的。如果你直接尝试INSERT INTO v_order_detail ...，SQLite会报错。但是加上一个INSTEAD OF触发器，就能把对视图的插入操作拆解为对两张基础表的写入：

sql复制CREATE TRIGGER trg_v_order_detail_ai_insert
INSTEAD OF INSERT ON v_order_detail
FOR EACH ROW
BEGIN
    INSERT INTO orders(order_id, customer_name, total_amount)
    VALUES(NEW.order_id, NEW.customer_name, 0);

    INSERT INTO order_items(order_id, product_name, quantity, price)
    VALUES(NEW.order_id, NEW.product_name, NEW.quantity, NEW.price);

    UPDATE orders SET total_amount =
        (SELECT SUM(quantity * price) FROM order_items WHERE order_id = NEW.order_id)
    WHERE order_id = NEW.order_id;
END;

这段逻辑里最关键的点是：当应用层对视图执行INSERT时，真实发生的事情是插入了两条主从记录，并随后重新计算了主表的汇总金额。你看，视图在应用层看起来仍然是“一张可以插入的表”，而其内部复杂性被触发器给包住了。这个设计对读取方非常友好，能让各种数据报表、临时导出工具直接复用一套插入逻辑，而不用每个工具都自己拼两条INSERT语句。

不过要提醒一句，INSTEAD OF触发器里你要妥善处理主键生成策略。上面这个例子在真实场景中，order_id经常由应用层或序列提供，如果你指望数据库自增，则需要根据你的实际表结构调整插入逻辑，不能原样照搬。

4. 触发器和“存在就更新，不存在就新增”的纠缠

很多人在搜SQLite触发器时，通常会带着一个非常具体的业务需求：存在就更新，不存在就新增。这是个经典需求，但这跟触发器不是一回事。实际上SQLite本身有原生语法来解决这个问题——UPSERT。不过在触发器内部使用UPSERT，也有一些值得注意的细节。

4.1 原生UPSERT与触发器的区别

先看原生UPSERT的写法，SQLite从3.24.0版本开始支持，写法是：

sql复制INSERT INTO user_points(user_id, points, updated_at)
VALUES(1001, 50, datetime('now', 'localtime'))
ON CONFLICT(user_id) DO UPDATE SET
    points = excluded.points,
    updated_at = excluded.updated_at;

这里excluded代表的是“本来要插入但因冲突被拦下的那一行”。如果user_id=1001这条记录已存在，就会走DO UPDATE的逻辑。

这个做法的好处是单条语句，不需要触发器，执行效率也很高。但如果你需要在这次更新前后补做更多动作，比如写审计日志、维护汇总表，那一条UPSERT就Hold不住了。这时候可以用“INSERT触发器”和“UPDATE触发器”搭配来打一套组合拳。

4.2 在触发器中完成“不存在就插入，存在就更新”

思路概括起来是：给表建一个BEFORE INSERT的触发器，在里面做存在性判断，如果记录已存在，就转为UPDATE并跳过本次INSERT。

但这里有一个非常关键的陷阱。如果你在BEFORE INSERT触发器里对同一张表执行UPDATE，在SQLite默认配置下（递归触发关闭）它不会再次触发UPDATE触发器，但会让原有INSERT语句继续执行，结果你就可能插入一条重复数据，或者因为主键冲突报错。要避免这个问题，正确做法是配合RAISE(IGNORE)，让INSERT语句之外的后续插入动作不再执行。

下面是一个比较典型的实现。设有一张用户表users，user_id是主键：

sql复制CREATE TRIGGER trg_users_bi_upsert
BEFORE INSERT ON users
FOR EACH ROW
WHEN EXISTS(SELECT 1 FROM users WHERE user_id = NEW.user_id)
BEGIN
    UPDATE users
    SET name = NEW.name,
        email = NEW.email
    WHERE user_id = NEW.user_id;

    SELECT RAISE(IGNORE);
END;

执行过程是这样的：当用户插入的user_id已经存在，触发器先进到WHEN条件，发现存在性为真，就执行了UPDATE，把名字和邮箱刷新成新值；然后RAISE(IGNORE)让原始INSERT语句被静默跳过，执行结束。如果user_id不存在，WHEN条件为假，什么都不做，INSERT正常写入。

这个方法在需要在同一事务里维护多张关联表的时候比较有用。但其实说实话，像上面这个简单场景，直接写UPSERT显然更干净。我会建议你把UPSERT作为默认首选，只有在需要额外逻辑时才考虑触发器方案。

4.3 触发器与UPSERT共存的事件顺序

当一条UPSERT语句实际执行了更新分支时，SQLite只会触发UPDATE触发器，不会触发INSERT触发器。当执行了插入分支时，只会触发INSERT触发器。这一点很多人一开始没注意，写了个UPSERT，以为INSERT触发器会执行，结果审计日志缺了几行。

前几年我被这个坑过一次。当时做一套数据同步程序，程序里用UPSERT去同步外部数据，为了记录同步痕迹建了AFTER INSERT触发器。结果运行了一段时间，发现很多同步进来的数据没有留下审计记录，排查半天才发现UPSERT在冲突时走的是UPDATE路径，而同步程序大部分时候都是重复数据，每次都在更新。那个AFTER INSERT触发器根本就没触发过几次。

解决方案有两个：要么把审计放进AFTER UPDATE触发器，要么在同步程序里明确区分INSERT和UPDATE两条路径。前者对写程序的人来说最省事，但会造成大量UPDATE审计记录。建议还是根据你实际业务对“完整可追溯性”的要求来取舍。

5. 递归触发、工具选择与实战排查

5.1 递归触发开关与循环终止的保命技巧

前面提过，SQLite的默认行为是不允许直接递归的。但PRAGMA recursive_triggers被打开后，间接递归就可能发生。

一个我自己实战中写过的例子——分类表category，每个分类有parent_id指向父分类，要维护一个path字段记录完整祖先路径。比如三级分类“手机/苹果/iPhone 15”的path是“/手机/苹果/”。如果分类名称改了，所有子孙分类的path都要级联更新，这是典型的递归需求。

在打开的递归触发条件下，可以写这样的触发器：

sql复制CREATE TRIGGER trg_category_au_update_path
AFTER UPDATE OF name ON category
FOR EACH ROW
WHEN OLD.name IS NOT NEW.name
BEGIN
    UPDATE category
    SET path = (SELECT path FROM category WHERE id = NEW.parent_id) || NEW.name || '/'
    WHERE parent_id = NEW.id;
END;

每一次父类名称变更，会触发本触发器，它去更新子分类；而子分类的UPDATE又触发子分类的子孙更新，一层层往下传导。看起来十分优雅。

但为了防止万一逻辑写错导致无限递归，触发后SQLite默认有递归上限（默认为1000层），超出后数据库会报错终止，不会真的把进程拖死。理论上这是第一层安全网。更稳的做法是WHEN条件保证只在必要情况下修改path，比如WHERE parent_id = NEW.id这样只锁直接子级，不锁后代；间接作用于后代时，由这些后代行的UPDATE自己触发后续链路的对应行。层层收敛，逻辑上是有终止性的。

5.2 工具选择：DB Browser for SQLite与命令行

选对工具，能省一半的精力。

DB Browser for SQLite（通常简称为DB Browser）是我个人最常用的图形化管理工具，开源免费，Windows/macOS/Linux都有对应版本。它有一个专门的“触发器”页签，打开数据库就能看到全局所有触发器的列表，点进去能直接看到触发器的定义SQL，还支持快速新增、修改和删除。

有些刚入门的人会去搜“db browser for sqlite中文版下载官网”，但其实这个工具本身就内置了中文界面语言，下载官方原版根本不需要额外的汉化包。直接去官网下载安装后，在菜单里把语言切换成中文就行。顺便提一句，官网地址是sqlitebrowser.org，认准这个，网络搜索时排在前面那几个带“中文版”“破解版”字样的网站反而要多留个心眼，个人不推荐从不明渠道下载数据库工具。

命令行方面，我经常在自动化脚本里直接使用sqlite3 CLI。这里给一个脚本化部署触发器的示例。把触发器写到一个.sql文件里，然后在shell中执行：

bash复制sqlite3 myapp.db < deploy_triggers.sql

如果你要确认触发器是否已经建好，可以在sqlite3命令行执行：

sql复制SELECT name, type FROM sqlite_master WHERE type = 'trigger';

如果想查看某项特定触发器的完整定义：

sql复制SELECT sql FROM sqlite_master WHERE type = 'trigger' AND name = 'trg_users_bu_autotime';

sqlite_master是SQLite内部维护的元数据表，所有触发器定义都存在里面。看清楚触发器里写的是什么逻辑，这是在排错之前必须要做的一步。DB Browser的图形页签本质上也是帮你对这张表做了个可视化查询，理解了这个底层原理，你在不受图形界面的环境下也能动手排查。

另外在涉及把MySQL的数据结构同步到SQLite、或从别的库导出函数/触发器数据时，不要指望数据文件直接平移。不同数据库方言差距巨大，正确做法是先导出SQL定义文本，再逐条改写为SQLite语法，最后在SQLite环境的测试库里做一次全量建库验证。尤其要警惕那些“一键转换”工具输出的结果——字段类型、自增语法、触发器里使用的函数都很可能不兼容。

5.3 触发器联调与调试三板斧

SQLite的触发器就像一个黑洞，如果它执行出错了，外部程序拿到的往往只是一个笼统的“database disk image is malformed”或者“constraint failed”，具体哪一行、哪个触发器出的问题，它不大会告诉你。所以建立一套自己的联调习惯特别重要。

第一板斧：先做单步验证。建完触发器后，立刻手工执行一条对应的INSERT、UPDATE或DELETE语句。然后再用SELECT查看表里的结果是否符合预期。比如建了审计触发器，就手动UPDATE一行数据，立刻去points_audit_log里看有没有新记录。

第二板斧：临时在触发器里埋点。在不影响生产数据的前提下，可以把触发器执行体的SQL临时改为向一张调试日志表插入消息。比如：

sql复制INSERT INTO debug_log(msg) VALUES('trigger fired at ' || datetime('now'));

运行完看看debug_log表有没有新增行，以此确认触发器是否真的被触发到了。用完记得删除调试日志代码。

第三板斧：给执行体SQL做单元化。如果你怀疑触发器里某条INSERT语句有问题，先把触发器里的语句复制出来，代入真实的字段值手动执行一遍，看会不会报错。触发器语法和普通SQL没有本质区别，它只是被包装在触发器的壳里，所以完全可以单独验证内部语句的正确性。

5.4 高频问题速查表

我把这几年被问到最多的、以及我自己踩过的坑整理成一个速查表，希望对你有帮助：

5.5 性能：触发器会不会拖慢我的应用

一句话回答：本地小数据量场景，触发器对性能的拖累几乎可以忽略；但如果一张表频繁大批量更新，且触发器逻辑复杂，就必须考虑开销。

触发器的耗时主要花在三个地方：触发动作的行扫描、内部SQL的解析执行、以及当触发器内部去访问其它表时的磁盘I/O。如果你的表每次UPDATE都会执行一个复杂的子查询，这个代价就会比较可观。

如果你发现触发器确实是性能瓶颈，最有效的优化手段是把一些运行频繁、耗时高的逻辑从触发器挪到业务层或建缓存表。比如“总金额=SUM(明细金额)”，如果订单表每次更新都重新全表汇总所有明细，那在千万级明细下性能会非常难看。更合理的方案可能是只汇总增量部分，或者延迟到查询端再做聚合。

另外提醒一句：SQLite的事务是串行写模型，写操作多的时候都按顺序排队。触发器会把一条写语句的事务周期拉长，等于把这条队缩短了。如果一个应用频繁执行几百行批量UPDATE，而每行都触发一次重型审计，整体耗时可能从几十毫秒膨胀到秒级。这个问题在数据同步场景中尤其常见。

我用了好几年的体会是，写触发器要克制。能用业务代码控制的地方，就别往数据库里塞太多隐藏逻辑；而涉及数据完整性和一致性底线的地方，业务代码反而替代不了。

5.6 数据库文件备份时如何保证触发器不丢

最后提一个经常被忽略的点：触发器不会因为你把CREATE TABLE语句复制走而自动跟着走。如果备份时只是把几张业务表的结构导出来，触发器、索引、视图这些都会落掉。用DB Browser操作时，注意勾选导出对象里的“触发器”选项。用命令行的话，备份应当用SQLite自己的备份机制：

bash复制sqlite3 source.db ".backup backup.db"

.backup命令会在文件级别做一致性备份，比较可靠。如果你只是想迁移表结构，那建议用.dump导出时把trigger相关SQL也一并dump出来。

bash复制sqlite3 source.db ".dump"

.dump输出里会包含创建触发器的完整SQL语句，拿到新环境执行一遍即可。

我在最初用SQLite的时候，就曾经因为只同步表结构而漏了触发器，结果在测试环境跑得好好的功能一到生产环境就“失灵”，查了一个下午才发现是生产环境的触发器没部署上去。后来我把所有数据库对象的定义SQL全部纳入版本管理，部署时统一执行，再也没出过这类问题。这个方法现在也推荐给所有身边的朋友，尤其是用SQLite做本地存储的客户端项目，部署升级时一定要带上触发器的变更脚本。

说到底，SQLite触发器是一种用起来特别“稳”的机制。只要你对它的边界有了清晰认知，按场景选对方案，它能把脏活累活全部揽到数据库内部，让你的业务代码干净又可靠。