公平地说,我看到了一些类似的问题here和 here但我相信这些问题主要询问单行更新以及假设实际数据没有改变。
就我而言,我有一组销售代表可以提供的产品。这些整体产品由定义它们的主表维护:
主表
ID | Name | status
---------------------
1 | prod1 | 1
2 | prod2 | 1
3 | prod3 | 0
4 | prod4 | 1
其中 status 表示事件 (1) 或非事件 (0)。任何代表都无法销售非事件产品,无论他们在代表表中的设置如何。
代表表
ID | repID | status
------------------------
1 | rep1 | 1
2 | rep1 | 1
3 | rep1 | 1
1 | rep2 | 0
2 | rep2 | 1
3 | rep3 | 0
此表中的状态是事件 (1) 或非事件 (0)。同样,在决定销售代表可以提供哪些产品方面,主表的状态总是覆盖 rep_table 状态。
我遇到的主要问题是当我们推出新产品供销售代表销售时。在代表的管理门户中,他(她)能够激活或停用他们希望提供的任何产品集。当用户选择(表单复选框)他/她希望销售的所有产品并点击提交时,一系列检查开始:
- 代表是否选择了一组产品?
- 是否以正确的格式选择了产品?
- 所选产品的列表是否与他们登录时已经设置的不同(如果不同,提醒不会发生更新)?
- 表格中选择的所有产品是否都存在并在 master_table 中设置为“事件”?
此时,对于每个选定的产品,逻辑将(当前)切换为以下内容:
- 将 rep_table 中的所有产品更新为非事件(针对该特定代表)
- 如果该产品在登录时存在于当前产品集中,并且当前状态设置为非事件,则将该产品 ID 排队等待事件。
- 如果通过的产品在登录时在当前产品集中不存在,则将新产品插入 rep_table 并设置为事件状态。
在“更新”语句开始时将特定代表的所有产品更新为非事件的主要原因是发现登录时设置为“事件”的哪些产品更改为“产品选择表上的“无效”。
我想知道是否不是试图弄清楚当前产品选择的状态相对于代表登录时的状态,而是首先删除 rep_table 中特定 repID 的所有产品 ID 是否更容易然后一次全部插入。我知道在这种情况下我运行了 2 个查询,但是在我在同一个命令中进行更新和插入的情况下,无论如何我每次至少运行 2 个以上的查询。
以这种方式删除和插入是否有“技术”意义?
注意:我的表是 InnoDB,我正在运行 MySQL
最佳答案
根据您的索引方式,删除和插入在技术上可能是性能的最佳选择。尽管如此,如果您有良好的索引,那么使用索引的 UPDATE 或 REPLACE 语句不值得担心删除所有数据然后重新插入。
如果 Delete 语句通过,但在您可以发出插入之前,您的服务器会重新启动 apache 并且内存被转储……这似乎有些牵强,但可能会发生。更多的用户、更多的更新、更可能的更改……您可以将 DELETE 和 INSERT 放在一个事务中,但现在您可能锁定了一个表——这也会影响性能。
关于php - 与 DELETE ALL 和 INSERT 相比,UPDATE OR INSERT 命令有技术优势吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17981528/