触发器无法跨分片执行聚合SQL，因其作用域严格限定在单个数据库实例内，无法访问其他物理分片表；替代方案是应用层双写汇总表、定时任务拉取合并或通过ShardingSphere-JDBC路由执行跨分片查询。
触发器无法直接跨分片表执行聚合
SQL 触发器（CREATE TRIGGER）作用域严格限定在**单个数据库实例、单个逻辑库内**，无法感知或访问其他物理分片上的表。哪怕你用 sharding-jdbc 或 ProxySQL 做了逻辑统一入口，触发器本身仍运行在底层 MySQL/PostgreSQL 实例上，INSERT INTO shard2.orders 这类跨库引用在触发器里会直接报错：ERROR 1146 (42S02): Table 'shard2.orders' doesn't exist（当前实例压根没这个库）。
常见误操作是试图在分片 A 的 orders 表上建触发器，然后在触发器里写 SELECT SUM(amount) FROM shardB.orders WHERE user_id = NEW.user_id —— 这条语句在分片 A 的 MySQL 进程里根本解析不过。
替代方案：用应用层或中间件完成跨分片聚合
真正可行的路径是把聚合逻辑从数据库层上移到可控的业务层或专用服务层：
- 应用代码中，在每次订单写入后，主动调用分片路由 SDK（如
ShardingSphere-JDBC的ShardingSphereDataSource）执行跨分片SELECT SUM(amount) FROM orders WHERE user_id = ? GROUP BY user_id，再写入汇总表； - 用定时任务（如
xxl-job或airflow）按小时/天拉取各分片orders表的增量数据（通过create_time > ?+ 分片键范围），合并后写入中心汇总库； - 若用
ShardingSphere-Proxy，可开启distsql的CREATE READWRITE_SPLITTING RULE配合广播表，但注意：广播表只适合低频更新的维度表，不适用于高频写入的订单明细聚合。
如果坚持用数据库机制，只能退回到“汇总表+应用双写”模式
这是最务实、线上验证过的做法，关键点在于放弃“自动触发”，改由应用显式维护：
- 应用在插入分片
orders同时，也同步执行一条INSERT INTO summary_user_amount (user_id, total_amount) VALUES (?, ?) ON DUPLICATE KEY UPDATE total_amount = total_amount + VALUES(total_amount)； - 汇总表
summary_user_amount必须设计为单库单表（不拆分），且主键user_id作为唯一约束； - 务必加
FOR UPDATE或使用乐观锁（如带version字段）防止并发写导致金额丢失——多个分片订单几乎同时提交时，两次UPDATE可能基于旧值计算，造成汇总不准。
为什么不能依赖数据库物化视图或 FEDERATED 引擎？
MySQL 的 FEDERATED 引擎理论上能跨实例查表，但它在 8.0 中已被移除，5.7 仅支持基础 SELECT，不支持聚合函数下推，性能极差，且事务隔离完全不可控；PostgreSQL 的 postgres_fdw 虽支持远程聚合，但跨分片场景下无法保证各分片事务一致性（一个分片提交成功、另一个失败时，视图结果就脏了）。这些方案在线上高并发 OLTP 场景中基本等于埋雷。
跨分片聚合的本质是分布式状态维护问题，数据库触发器天生不具备协调能力。真正要稳定跑起来，得接受“聚合不是实时的”“必须靠应用或调度兜底”这个前提。
