rid*_*rid 18 mysql performance
如果我SELECTID然后UPDATE使用这些ID,那么UPDATE查询比我UPDATE使用中的条件更快SELECT.
为了显示:
SELECT id FROM table WHERE a IS NULL LIMIT 10; -- 0.00 sec
UPDATE table SET field = value WHERE id IN (...); -- 0.01 sec
上述速度比UPDATE相同条件快100倍:
UPDATE table SET field = value WHERE a IS NULL LIMIT 10; -- 0.91 sec
为什么？
注意:a列已编入索引.
Max*_*sky 30
很可能第二个UPDATE语句会锁定更多行,而第一个语句使用唯一键并仅锁定它要更新的行.
这两个查询并不相同。您只知道 ID 在表中是唯一的。
UPDATE ... LIMIT 10 最多更新 10 条记录。
如果有重复的 id，UPDATE ... WHERE id IN (SELECT ... LIMIT 10) 可能会更新 10 条以上的记录。
我认为对于您的“为什么？”没有一个直接的答案。无需进行某种分析和研究。
SELECT 查询通常会被缓存，这意味着如果多次运行同一个 SELECT 查询，第一个查询的执行时间通常大于后续查询。请注意，只有在 SELECT 很重的情况下才能体验到这种行为，而在即使是第一个 SELECT 也快得多的情况下也不会。因此，在您的示例中，由于缓存，SELECT 可能需要 0.00 秒。UPDATE 查询使用不同的 WHERE 子句，因此它们的执行时间很可能不同。
虽然该列a已被索引，但在执行 SELECT 或 UPDATE 时，MySQL 不一定必须使用该索引。请研究 EXPLAIN 输出。另外，查看输出SHOW INDEX并检查“评论”列是否为任何索引读取“禁用”？你可以在这里阅读更多 - http://dev.mysql.com/doc/refman/5.0/en/show-index.html和http://dev.mysql.com/doc/refman/5.0/en/mysql-索引.html。
此外，如果我们暂时忽略 SELECT 并只关注 UPDATE 查询，很明显它们并没有使用相同的 WHERE 条件——第一个在idcolumn 上运行，后者在a. 虽然两列都被索引，但并不一定意味着所有表索引的表现都一样。根据索引的大小或索引列的数据类型，或者它是单列还是多列索引，某些索引可能比其他索引更有效。当然可能还有其他原因，但我不是这方面的专家。
此外，我认为第二个 UPDATE 正在做更多的工作，因为与第一个 UPDATE 相比，它可能放置了更多的行级锁。确实，两个 UPDATES 最终都更新了相同数量的行。但是在第一次更新中，锁定了 10 行，我认为在第二次更新中，所有a为 NULL（大于 10）的行在执行更新之前都被锁定。也许 MySQL 首先应用锁定，然后运行 LIMIT 子句以仅更新有限的记录。
希望以上解释有道理！