简单的SQL Update 语句变的超级慢

已经有where条件了，不需要再用子查询去关联了吧？不是找慢么。

update

a

set

col1=xx

where

[条件]

写成这样，看得人费解。你到底是更新呢还是查询？

简单的看看搂主的描述 "需要从B表中一条一条去A表中核实"

我估计是用 游标来处理的。

如果用游标一行一行 FETCH ， 性能可能要打点折扣。

这种情况下，可以尝试使用 BULK COLLECT 来批量加载。

下面是 Oracle 游标处理II - 使用BULK COLLECT 的例子。

>

你这样写很不好，看起来写的是一句sql，反而速度慢下来了。首先row_number() over() as rownum毫无必要，这样来分页效率不高。然后能不用就不用查询。在大数据量和列很多的情况下，会慢很多。

而且你也说了，更新1W条数据需要半个小时。那么可以采用存储过程或者程序来访问。这样会快很多，推荐采用存储过程，110W条数据，就算重建索引等，更新一条应该在200ms一下，一万条，不会那么久的。希望能帮助得到你。

你这样写sql语句，执行时间太久了，会造成假死现象，这样很不好。

问题

我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 57 上运行特别慢，怎么办

实验

我们搭建一个 MySQL 57 的环境，此处省略搭建步骤。

写个简单的脚本，制造一批带主键和不带主键的表：

执行一下脚本：

现在执行以下 SQL 看看效果：

执行了 1680s，感觉是非常慢了。

现在用一下 DBA 三板斧，看看执行计划：

感觉有点惨，由于 information_schemacolumns 是元数据表，没有必要的统计信息。

那我们来 show warnings 看看 MySQL 改写后的 SQL：

我们格式化一下 SQL：

可以看到 MySQL 将

select from A where Ax not in (select x from B) //非关联子查询

转换成了

select from A where not exists (select 1 from B where Bx = ax) //关联子查询

如果我们自己是 MySQL，在执行非关联子查询时，可以使用很简单的策略：

select from A where Ax not in (select x from B where ) //非关联子查询:1 扫描 B 表中的所有记录，找到满足条件的记录，存放在临时表 C 中，建好索引2 扫描 A 表中的记录，与临时表 C 中的记录进行比对，直接在索引里比对，

而关联子查询就需要循环迭代：

select from A where not exists (select 1 from B where Bx = ax and ) //关联子查询扫描 A 表的每一条记录 rA：     扫描 B 表，找到其中的第一条满足 rA 条件的记录。

显然，关联子查询的扫描成本会高于非关联子查询。

我们希望 MySQL 能先"缓存"子查询的结果（缓存这一步叫物化，MATERIALIZATION），但MySQL 认为不缓存更快，我们就需要给予 MySQL 一定指导。

可以看到执行时间变成了 067s。

整理

我们诊断的关键点如下：

\1 对于 information_schema 中的元数据表，执行计划不能提供有效信息。

\2 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。

\3 我们增加了 hint，指导 MySQL 正确进行优化判断。

但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。

可能是LOAD之后这个表的统计信息没有更新，你们可以使用REORGCHK或者RUNSTATS命令将此表的统计信息更新一下。 因为DB2执行计划的选择是根据这些统计信息，假如信息没有及时更新，就有可能将索引扫描判断成全表扫描。

select from

(

select a,row_number() over(partition by 分组字段 order by 排序字段) rn from table

) b where rn = 1

上边的可以取一条出来，主要看你的分组字段和排序字段的设置

以上就是关于简单的SQL Update 语句变的超级慢全部的内容，包括:简单的SQL Update 语句变的超级慢、高分求助：oracle 大表更新，大约200万，insert和update太慢，如何解决、DB2数据库更新数据缓慢，求优化建议等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！