在执行删除之前先进行选择计数还是盲目地调用删除是否更好？
我正在寻找最佳实践/想法，看看是否最好进行选择计数并检查结果是否> > 0 在调用删除之前，或者即使数据不存在，最好还是盲目地在数据库中触发删除语句。在我们的例子中，大多数时候数据都不存在。
那么什么是更好的：
Option 1: call Select Count(X) where foo, if result > 0, delete where foo
或者
Option 2: delete where foo
出于速度原因我倾向于盲目删除，因为无论如何你都会进行表命中。
编辑：这实际上发生在kettle（一种ETL工具）中，因此如果存在删除，这三个操作将完全分开完成。所以完全用 SQL 不是一个选择。
I'm looking for a best practice / thoughts on if it is better to do a select count and checking if the result is > 0 before calling a delete or if it would be better to just blindly fire a delete statement at the database even if the data doesn't exist. In our case most of the time data will NOT exist.
So what is better:
Option 1: call Select Count(X) where foo, if result > 0, delete where foo
or
Option 2: delete where foo
I lean towards the blind delete for speed reasons and since you are doing a table hit anyways.
EDIT: This is actually happening in kettle(an ETL tool) so the three operations will be done completely separate if there is a delete. So completely in SQL is not an option.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我只会删除，如果您尝试删除不存在的内容，它只会删除 0（零）行。这也减少了前往数据库的次数。
I would just delete, if you try to delete something that is not there, it will just delete 0 (zero) rows. This reduces the amount of trips to the DB as well.
我想说我会盲目地进行删除，然后取回受影响的行数。
无论哪种情况，比较完成后，执行时间应该几乎相同。
I would say I would do the delete blindly, and then get back the number of rows affected.
In either cases, the comparison is done, it should be almost the same execution time.
只需去删除即可。预先发出 count(*) 没有任何优势。
Just go for the delete. There is no advantage in issuing a count(*) beforehand.
通用的 IT 答案以“It Depends”开头，
这里取决于删除的查询计划。
如果您执行使用索引或更好的查询计划的 EXISTS 查询（根据 OMG-Ponies），那么效果会更好、更快。
这样也许可以避免使用表扫描进行不必要的删除。
The universal IT answer is prefaced with "It Depends"
Here it depends on the query plan of the Delete.
If you do an EXISTS query (per OMG-Ponies) that uses an index or a better query plan, that would be better-faster.
An unneeded delete that uses a table scan could then perhaps be avoided.