sql中 的update  set  怎么用啊

说实话，如果你经常使用这个 UPDATE 东西，它确实会让人兴奋。
刚开始采用旧系统的时候，突然把几百条客户记录改成了“王老五”，因为WHERE条件没写对。
我花了半个晚上才把它找回来。

以您的示例中的作者表为例。
我也遇到过类似的情况。
有客户坚持要求批量更改作者姓名，结果姓氏被改为“张”。
原来，作者“安妮·史密斯”变成了“张·史密斯”。
尽管数据是正确的，但看起来很奇怪。
因此，更新时最好添加 LIKE 'Anne%' 之类的模糊匹配，以避免更改带有 'Anne' 的变体。

JOIN 的例子更有趣。
我之前有一个项目使用它来更新标题表中的 ytd_sales 。
原来，SQL Server在同一天向销售表中添加了几条记录，导致一些书籍的销量激增。
后来我使用 GROUP BY title_id 解决了它。
说实话，这种细节是最容易出问题的，尤其是数据量很大的时候。

另一个危险是更新期间处理 NULL。
例如，如果将 au_fname 更改为 NULL，则会发现某些作者未输入姓名。
如果直接更新的话，一切都会是NULL。
当时我使用 COALESCE 函数来处理这个问题，并将空字符串转换为 NULL 以避免数据丢失。

最烦人的是授权问题。
我的一位同事想要更新财务表，但由于权限不足，他只能使用存储过程来绕过它。
这个过程很难用一句话来描述，每次更新都要参考一下。
说实话，这个设计在当时确实很偷懒。

使用UPDATE时，我个人采用三步：先SELECT并运行记录看是否正确，确认没有问题再运行，最后SELECT确认更新成功。
虽然速度较慢，但​​无忧无虑。
我在您的示例中不经常使用 OPTION (query_hint)，但我只知道它存在。
我通常让 DBA 来更改 SQL Server 执行计划。

数据量小的话还可以。
一旦表包含数十万条记录，更新语句就会让人抓狂。
我之前有一张表，更新了5 00万条数据，CPU就到了1 00%。
最后我发现索引没有正确创建。
因此，更新前要确认索引，尤其是WHERE和SET中的字段。

顺便说一句，我也不经常使用WITH(table_hint_limited)。
有一次我尝试使用WITH（TABLOCKX）锁定表，但其他应用程序在更新时卡住了。
今天我们一般还是依靠WHERE条件和索引来控制范围。

更新最终是一把双刃剑。
如果使用得当，它是非常有效的，但如果使用不当，它就是一颗定时炸弹。
你写的例子相当标准，但在实际使用中，需要考虑到各种约束。
例如，ord_date 可能在 sales 表中重复，或者 title_id 可能碰巧在 title 表中具有 NULL 值。
这些细节一定要注意。

SQL中update语句怎么用 数据更新的4个关键要点

说实话，第一次使用UPDATE的时候，我吓出了一身冷汗。
当时我刚刚接手一个老项目，要求销售部门每个人加薪1 0%。
结果，我的手在颤抖，我失去了WHERE子句。
你猜怎么着？公司所有员工的工资都会暴涨，老板的血压计很可能第二天就烧坏了。
所以第一个“确保你的目标表是清晰的”实际上意味着你必须知道你在做什么，而不仅仅是知道如何写UPDATE表名。
我习惯在执行前检查表结构图（尤其是字段较多的表）。

有趣的是，设置新值时最令人沮丧的是数据类型不匹配。
我曾经在尝试将字符串值分配给 Oracle 中的日期字段时遇到令人眼花缭乱的错误消息。
后来我发现我需要使用传递函数 DBMS_UTILITY.to_date('2 02 3 -01 -01 ', 'YYYY-MM-DD') 这已经足够了。
这让我想起以前的运维人员，每次更新日期字段都要开个小会，讨论格式怎么写才不会出问题。

在限制更新范围方面，我有一个特别可怕的习惯。
在完成 WHERE 条件的编写之前，必须首先使用 SELECT 输出受影响的行。
记得有一次更新客户状态时，WHERE读到status='inative'（错别字），结果半个下午数据都变了。
然后我编写了一个小脚本，自动比较更新前后的数据量。
如果偏差超过5 %，将直接发出警报。
这个细节其实非常重要，特别是对于有很多记录的表。
缺少几百行可能会毁掉你的工作。

我个人认为设计数据库时应该明确考虑对NULL值的处理。
系统经历了一个接缝期，某些字段突然出现大量 NULL 值。
结果，我在编写 UPDATE WHERE NULL 时陷入困境。
在新系统中设计表时，向可能为空的字段添加默认值可以使更新变得更加容易。
虽然这不是严格意义上的SQL技能，但是在设计关系时应该考虑更新场景。

更新交叉表确实是一项技术任务。
以前，当我使用子查询来更新折扣时，当我有大量数据时，它就像爬行一样慢。
然后我切换到JOIN，表演立即开始。
但请注意，并非所有数据库都支持 JOIN 更新，因此您需要阅读文档。
我记得旧版本的SQL Server 相当麻烦。
我必须使用临时表或两个嵌套的更新。
新版本好多了。

最后，这里有一些性能优化技巧。
如果您使用索引，则应该在正确的位置使用它们。
我有一个同事坚持在 WHERE 条件下使用函数，但结果索引变得完全无用。
与您提到的 YEAR (hire_date) 示例类似，这简直就是对索引的侮辱。
不过，也有例外。
例如，如果某个特定表频繁更新，则删除索引并使用 IN 子句可以提高效率。
这个问题确实要看经验。
如果你跑得多了，你就会明白。