关于UPDATE的那些坑

本文介绍了一种常见的SQL更新语句错误:“You can't specify target table for update in FROM clause”,并提供了解决方案。通过调整子查询部分,避免直接在更新语句中引用目标表,从而成功更新数据。

废话不多说,请看代码:

UPDATE 
    my_return 
SET next_settlement_time = date_sub(r_return_day,interval -1 day)
WHERE r_id IN (
    SELECT  r.r_id
    FROM my_borrow_apply b
    LEFT JOIN my_return r ON r.b_id=b.b_id
    WHERE b.partner_id = 26 and b.fund_id = 183
)

错误:You can't specify target table 'my_return' for update in FROM clause

原因是:修改的表不能在子查询中出现。

正确的写法:

UPDATE 
    my_return 
SET next_settlement_time = date_sub(r_return_day,interval -1 day)
WHERE b_id IN (
    SELECT b.b_id
    FROM my_borrow_apply b
    WHERE b.partner_id = 26 and b.fund_id = 183
)

^ _ ^

 

### 关于 'ON DUPLICATE KEY UPDATE' 的常见问题及解决方案 #### 错误处理不当 当使用 `ON DUPLICATE KEY UPDATE` 时,如果遇到唯一键冲突,SQL 语句会尝试更新现有记录而不是插入新记录。然而,在某些情况下,可能会因为错误配置或其他原因导致操作失败。例如,试图更新的字段可能设置了不可更改的约束条件[^1]。 ```sql INSERT INTO table_name (id, name) VALUES (1, 'Alice') ON DUPLICATE KEY UPDATE name=VALUES(name); ``` 上述 SQL 语句中,假设 `id` 是唯一的主键。如果有重复的 `id` 值,则执行更新操作;否则插入新的数据行。但如果表结构定义不允许修改特定列(如自增 ID),则该命令将会报错。 #### 数据一致性风险 另一个潜在问题是数据的一致性和完整性。如果不小心选择了不合适的字段用于更新,可能导致意外的数据覆盖或丢失重要信息。因此建议仅针对那些确实需要被刷新的属性应用此机制,并且要充分测试其行为以确保不会破坏已有数据[^2]。 #### 性能影响 频繁触发 `ON DUPLICATE KEY UPDATE` 可能在高并发场景下给数据库带来额外负担。特别是对于大型哈希键(BigKey),由于缺乏定期清理无效条目而导致成员数量持续增长的情况,这将进一步加剧性能瓶颈并引发大键问题。 为了缓解这些问题: - **优化索引设计**:合理规划唯一键和其他索引来减少冲突发生的概率; - **批量处理请求**:通过批量化写入来降低单次事务的影响范围; - **监控与调优**:密切跟踪系统表现指标,及时调整参数设置提高效率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值