分区表触发器不能跨分区操作数据，因mysql触发器不感知分区结构，仅在当前行所在分区执行读写，且禁止修改分区列导致行迁移、易引发锁竞争与死锁，null分区键需显式处理。
分区表触发器不能跨分区操作数据
MySQL 触发器本身不感知分区结构，但当触发表是分区表时，BEFORE 或 AFTER 触发器仍按单表逻辑执行——即每行只属于一个物理分区，触发器体中对本表的读写操作（如 SELECT、UPDATE）仍受限于当前行所在分区。这意味着：
- 在
BEFORE INSERT中尝试SELECT ... FROM same_partitioned_table WHERE x = ?，MySQL 仍需扫描所有匹配分区（而非仅目标分区），除非WHERE条件能被准确 pruned -
AFTER UPDATE中若用子查询更新本表，可能因分区裁剪失败而报错ERROR 1442（尤其当子查询含函数或非分区列条件时） - 分区表达式含
NULL时（如PARTITION BY RANGE YEAR(created_at)），触发器内对created_at的判断可能误入第一个NULL分区，导致逻辑偏差
触发器无法绕过分区键限制执行 DML
MySQL 不允许触发器中对触发表执行“违反分区约束”的语句。例如：
- 若表按
PARTITION BY RANGE COLUMNS(order_date)分区，且某行order_date = NULL被路由到p_nulls分区，则BEFORE INSERT中试图SET NEW.order_date = '2025-01-01'是合法的；但若直接INSERT INTO same_table VALUES (...)插入一条order_date = NULL的记录，该行仍会进入p_nulls，不会因触发器修改而改变分区归属 - 更关键的是：
UPDATE触发器中修改分区列（如SET NEW.order_date = ...）会导致行迁移（relocation），而 MySQL 在触发器上下文中禁止这种隐式跨分区移动——此时会静默失败或抛出ERROR 1690（depending on version and strict mode）
分区表 + AFTER 触发器易引发锁竞争与死锁
分区表的每个分区有独立的锁粒度，但 AFTER 触发器在事务提交前执行，其内部语句可能意外扩大锁范围：
-
AFTER INSERT中若调用UPDATE other_partitioned_table ...，而该表也按相同列分区，MySQL 可能因无法预判目标分区而锁定多个分区的索引段 - 当两个并发事务分别插入不同分区，但触发器都尝试更新同一张日志表的全局计数器（如
UPDATE stats SET total = total + 1），容易在该日志表上形成行锁冲突 - MySQL 5.7+ 对分区表的元数据锁（MDL）管理更严格，触发器中嵌套访问其他分区表时，可能因 MDL 等待链过长触发超时（
Lock wait timeout exceeded）
BEFORE 触发器中分区列校验必须显式处理 NULL
分区键列允许为 NULL，但触发器逻辑常默认其非空。例如：
- 定义
PARTITION BY RANGE TO_DAYS(order_date)，TO_DAYS(NULL)返回NULL，该行落入第一个分区 - 若
BEFORE INSERT中写IF NEW.order_date ，则 <code>NEW.order_date IS NULL时整个条件为UNKNOWN，校验失效 - 正确做法是显式判断：
IF NEW.order_date IS NULL OR NEW.order_date
分区表本身不增加触发器语法复杂度，但放大了原有约束的副作用——尤其是锁行为、NULL 处理和分区裁剪不可靠这三点，最容易在线上突然暴露。
