sql中如何更新数据 数据更新语句的注意事项分享

上周我和同事讨论了这个 SQL 更新问题。
确实有几点需要注意。

首先是索引优化。
例如，在处理2 02 3 年1 0月的用户表时，我们发现电子邮件更新速度极其缓慢。
后来加上了idx_email索引，速度直接快了9 0%。
但请注意，对于使用 WHERE UPPER(email) = 'ABC' 等函数的查询，索引将无效。
我不知道是否要为这部分创建专门的功能索引，这要看情况。

批量更新也是必不可少的。
我们在 2 02 2 年更新了数百条记录，并且很长一段时间都只停留在一次更新上。
最终我改用临时表+JOIN的方式，花了十分钟。
我这里没有代码，但这可能意味着先插入临时表，然后更新关联。

WHERE条件不可疏忽。
之前有一次忘记加条件了，整个表都变了。
后来在代码中添加了勾选，每次执行前都会显示一个确认框。
SQL Server还使用触发器来防止意外操作。

控制竞争也是一个令人头疼的问题。
去年测试环境出现了死锁，我花了很长时间才发现两个事务同时更新了相同的数据。
现在基本上都是采用乐观锁，并且增加了version字段。
每次更新都会检查版本号，如果不匹配，请重试。

最后就是性能优化。
更新时，我们只更改必要的字段，例如状态字段。
我曾经看到人们将电子邮件放入 SET 中，但这不是必需的。
还有合并的UPDATE，比如UPDATE users SET name='name1 ' WHERE id=1 ，name='name2 ' WHERE id=2 ，数据库好像不支持。

算了，你懂的。

电脑中的数据库在哪？又怎么更新？

几年前，我在公司计算机上遇到了这个问题。
当时，我们正在使用客户关系管理（CRM）系统。
突然有一天，我打开软件时，弹出一条消息说“数据库已过期”。
我一看，就觉得出了什么问题。
后来查了一下，原来这个CRM软件是基于中央数据库的。
该数据库中的信息已更新，但我们计算机上的本地数据库未更新，因此软件存在问题。

当时我的心砰砰直跳，生怕影响工作。
然后我问了IT部门的人，他们告诉我这其实是一个小问题，可以通过更新数据库来解决。
我按照他们的指示，在软件中找到“更新”按钮，点击它，然后电脑开始自动下载更新包。

当时，我们公司有数百人在使用这个CRM，并且更新数据库的过程相当缓慢。
我记得那段时间我偶尔会看看电脑屏幕，因为我担心更新会出问题。
幸运的是一切都很顺利，然后软件就恢复正常了。

还有一次，我朋友使用的杀毒软件也提醒我数据库已过期。
他当时并没有注意到，他的电脑已经感染了病毒。
我告诉他，杀毒软件的数据库已经过期，像未接种疫苗的人一样，他们很容易感染这种疾病。
然后他很快更新了数据库，电脑又安全了。

这件事让我明白，无论在工作还是生活中，遇到数据库过期等提醒时，都不要掉以轻心。
该更新就更新，不要让小问题变成大问题。
呵呵，现在回想起来，真是个陷阱啊！

高并发场景下，到底先更新缓存还是先更新数据库？

说白了，在高并发场景下，缓存优化策略的选择至关重要。
其实很简单。
尽管 CacheAside 策略很常见，但如果使用不当，可能会导致重大缺陷。
我们先来说说最重要的事情。
CacheAside策略由读请求和写请求两个过程组成。
例如，读请求首先判断缓存中是否有数据，如果命中则直接返回数据；如果缓存未命中，则从数据库查询数据，写回缓存，然后返回给客户端。
写查询通常会更新数据库，然后删除缓存，但是这里存在很多问题。

本以为先更新数据库再更新缓存就没有问题了，后来发现我错了。
例如，并发写入请求可能会出现数据不一致。
我们去年做的一个项目，大概有3 000次数据更新，就出现了缓存脏数据的问题。
另一个重要的细节是先删除缓存，然后更新数据库。
当读请求和写请求并发时，也会出现数据不一致的情况。

等等一件事。
虽然先更新数据库再删除缓存理论上是有问题的，但实际上更新数据库需要花费大量时间。
重写缓存的最后一步通常是在更新数据库之前完成的，因此出现问题的概率较低。
但出于安全原因，最好为缓存数据设置过期日期。
其他策略又如何呢？通读策略通过缓存提供者提供外部读写操作。
应用程序不需要知道操作的是缓存还是数据库，适用于多次请求相同数据的情况。
在Write-Through策略中，缓存提供者负责更新数据源和缓存，并且缓存与数据源保持一致。
writebehind策略写入速度较慢，适合频繁写入的情况，但缓存和数据库一致性不稳健。

总之，缓存机制通常会更新数据库，然后刷新缓存，设置缓存时间是安全的。
其他策略它们各有优缺点，应根据实际情况进行选择。
很多人没有注意到这一点，但我认为值得尝试。