问题标签 [table-locking]

我想知道为什么 MySQL 不允许在存储过程中锁定表。

我的存储过程中有以下 SQL 语句：

所以我必须锁定表comment以防止对其进行任何写入，因为它可能会导致在第一个 SQL 语句中选择的行数与实际更新的行数不同。

我有一个存储过程，它首先检查临时表（#temp_table），如果它存在则删除它，使用该表，然后在完成后最终将其删除。当用户执行某些操作来触发它时，该 SP 会被随机调用，并且有时 SP 可能会同时执行 - 或有一些重叠。

假设我有同一个 SP 的 Exec1 和 Exec2 创建、更改和删除 #temp 表，并且它们彼此运行在几毫秒内。

发生什么了？Exec1 会锁定 #temp_table 并且 Exec2 会在 Exec1 完成时等待吗？在我的情况下，这显然是可取的。我不希望 Exec1 和 2 同时使用该表，也不希望 Exec2 失败，因为 Exec1 已经在使用该表。

[编辑] 我应该将我的临时表转换为表变量吗？

我目前正在处理一项棘手的任务。

背景：

• 我有一个包含多个表和大量行的 MSSQL 2012 数据库。由于在此数据库中搜索需要相当长的时间，因此我寻找改进查询的方法。（是的，我正在使用索引，已经查看了执行计划和类似的东西:-)）经过一番调查，我在 MSSQL 2012 Enterprise 中找到了列存储索引。这让我在搜索过程中获得了巨大的性能提升。
• 缺点：启用索引后，无法插入/更新/删除数据

目标：

• 我想要快速搜索
• 应该可以一次运行多个工作人员来插入/更新/删除具有列存储索引的数据（在访问相同 表的多个工作人员之间拆分工作）（通常在夜间完成）
• 工作人员完成任务执行索引后，应重建（其他工作人员应等到那时）
• 之后工作人员应继续并在必要时再次禁用索引

当前解决方案：

目前有一个解决方案，但它不能 100% 工作，因为仍然会收到有时无法执行 UPDATES 和 INSERTS 的消息，因为应该首先禁用列存储索引（但它们应该根据我所做的）或者那里是在调用存储过程以操作数据期间出现的死锁。

一个简短的概述我做了什么。我不确定它是否是使用列存储索引更新表的最佳方法。还阅读了有关分区切换的信息，但当前未使用分区（由于数据结构和搜索）

我在 MSSQL 数据库中有以下存储过程。

sp_columnstore_entity_disable（禁用表上的索引）

sp_columnstore_entity_rebuild（重建表上的索引）

sp_entity_insert_update

worker 的程序代码如下所示：

问题：

有时我会收到错误消息，例如事务（进程 ID）在锁定资源上与另一个进程死锁，并被选为死锁受害者，我的进程崩溃。

有时我会收到错误，因为列存储索引处于活动状态，所以 INSERT 或 UPDATE 是不可能的。

我已经考虑过表锁在重建和修改期间不会遇到竞争条件。

我很高兴有任何解决问题的建议或帮助

我正在运行一个 python 脚本来执行 ETL（提取、转换、加载），并将所有 psql 查询放在一个事务中。这是交易：

我知道在运行 q4 时表会被锁定，但我不确定在整个事务（从连接到提交）期间表是否会被锁定？

有没有办法测试表是否被锁定？我现在没有太多数据（大约 100 行）..

非常感谢！

我在 AWS 上使用 innoDB。我的日志中不断收到大量以下消息：

等待表级锁

我以为 innoDB 只做行级锁。我的代码中没有任何锁表。有谁知道为什么会发生这种情况？

我正在使用 batchUpdate 插入 Oracle 表。五个不同的并行线程正在调用 batchUpdate 方法以插入单个表。表是全局临时表类型。

程序执行未完成，建立数据库连接后卡住。

多个线程在单个全局临时表上操作会导致表锁定并保持程序的执行吗？

我可以使用以下查询查看锁定的表 -

我正在开发一个使用 MySQL 数据库作为后端的项目（从 PHP 访问）。有时，我选择一行，对其进行一些操作，然后更新数据库中的记录。

我担心另一个用户可能会在第一次选择后立即在同一行上启动类似的过程，并且他的更改可能会覆盖第一个用户所做的一些更改（因为第二个用户的选择尚未包含这些更改）。

这是一个实际的问题吗？我应该锁定表吗？这不会严重影响我的应用程序的性能吗？还有其他解决方案吗？

为了全面了解我的信息，我还运行了一些 CRON 作业，它们也可能正在修改相同的数据。

谢谢！

我正在使用名为“tip”的最新标签，并且我正在按需使用 JIRA。

我刚刚将 JIRA 移动连接合并到我的 ios 应用程序中，它的行为有点奇怪，即它进入无限循环并挂起我的应用程序。开启调试模式，再深入一点，发现这个问题的根源是sqlite数据库表被锁定了。

事件的顺序如下：-

1. 我第一次启动我的应用程序
2. 我使用 JIRA 移动连接成功创建了一个问题
3. 我关闭了我的应用
4. 我通过 Web 界面在 JIRA 中在线添加评论来更新问题（以模拟 2 路通信场景）
5. 我重新启动了我的 ios 应用程序
6. JMC 使用https://xxxx.atlassian.net/rest/jconnect/1.0/issue/updates?sinceMillis=1408380024967&uuid=9371F70F-12CD-47EC-AB3E-4B0398FF453E&apikey=YYY&project=AAA-从JIRA rest api 获取更新能够找到我在第 4 步中所做的更新
7. 由于它发现更改，JMCIssueStore.m调用updateWithData其中包含逻辑的方法，即[self createSchema:YES]尝试删除现有的 2 个表并重新创建模式。
8. 在第一次尝试删除[db executeUpdate:@"DROP table if exists ISSUE"]表时，即发现数据库表被锁定，JMC 进入无限循环重试执行该语句。

我无法在 Atlassian Q&A 门户网站或网络上找到任何答案，我感到很惊讶，因为使用它的其他人肯定会遇到同样的问题，或者我在尝试整合它时做了一些明显错误的事情。

有没有人遇到过这个或类似的事情？由于这是我使用 JIRA Mobile Connect 的关键功能之一，我真的需要弄清楚是否值得为此调试 Jira Mobile Connect，或者只是放弃并从头开始。

我有一个每秒处理许多查询的系统。mysql我用和对我的系统进行编码PHP。

我的问题是mysqli事务仍然提交事务，即使记录被其他用户同时删除，我所有的表都在使用InnoDB。

这就是我使用 mysqli 编码交易的方式：

以下是另一个用户在其他脚本中同时执行的查询，然后最终弄乱了预期的系统行为，

请指教，我是否错误地执行了交易？我已阅读有关行级锁定的信息，并相信innoDB在事务期间确实会锁定记录

我正在阅读有关InnoDB's 隔离级别的内容，这在很大程度上是有道理的，但我不明白为什么是unrepeatable reads一件坏事？不应该反过来吗？

举些例子：

假设我们有一个用于销售产品的库存列，每次有人购买一件商品时，我们都会从该列中取出一件商品，使用Repeatable read或serializable隔离级别不会破坏数据完整性吗？

例如：

除非它在运行更新时使用正确的值？