每次我使用MySQL的CREATE TABLE AS SELECT ...时,从其中选择的所有表/索引都是在查询的持续时间()锁定的。我真的不明白为什么?有办法绕过这件事吗?
使用: MySQL 5.1.41和InnoDB
添加了示例:
例如,以下查询可能需要10分钟才能完成:
CREATE TABLE temp_lots_of_data_xxx AS
SELECT
a.*
b.*
c.*
FROM a
LEFT JOIN b ON a.foo = b.foo
LEFT JOIN c ON a.foo = c.foo
在上述查询期间尝试更新表a、b或c中的值将等待上述
先生们,现在有一个mysql集群.但还是下降了。这发生在两个节点的主机名更改之后。
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock /usr/local/mysql/data/ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using
Connection1:
BEGIN;
SELECT *
FROM world.city
WHERE ID = 130
FOR SHARE;
Connection2:
SELECT engine, thread_id, object_schema,
object_name, lock_type, lock_mode,
lock_status, lock_data
FROM performance_schema.data_locks;
+--------+-----------+---------------+-------------+-----------+--------------
我们的代码做到了
insert into user (email, name) values ((),()) // 1000 rows at a time, without specifying primary key value
这样的插入在多个服务器上并行运行,并且具有高并发性(有时甚至是2个并行),其中许多插入由于锁定等待超时而失败。显示innodb状态如下所示
mysql tables in use 1, locked 1
2592 lock struct(s), heap size 319696, 109498 row lock(s), undo log entries 51785
我正在使用PHP运行几个mysql查询,以更改几个表中的值。
基本上是这样的(简化的伪码)
$amount = (SELECT amount FROM wallet WHERE id = 1);
$amount = somelongcomplicatedtask($amount);
(UPDATE wallet SET amount = $amount WHERE id = 23);
可以有许多脚本并行使用mysql数据库(写/读),我需要确保以下内容:
如果其中一个查询失败,到目前为止完成的所有工作都将被恢复(我可以使用事务)。
当我使用表钱包(1和23)中的两行时,它们需要被锁定,
说SELECT FOR UPDATE设置一个IX锁。IX锁是意图排他锁,当发出时它意味着“事务T打算在扫描行上设置X(排它)锁”。这意味着在SELECT FOR UPDATE成功之前,它必须先获得IX,然后才能获得X。MySQL术语表表示,关于意图排他性锁:
意图锁定
一种适用于表级别的锁,用于指示事务打算在表中的行上获取什么样的锁。不同的事务可以在同一表上获取不同类型的意图锁,,但是获取表上的意图排他(IX)锁的第一个事务阻止其他事务获取表上的任何S或X锁。相反,获取表上的意图共享(IS)锁的第一个事务阻止其他事务获取该表上的任何X锁。两阶段进程允许按顺序解析锁请求,而不阻塞兼容的锁和相应
在我们的测试服务器上,我们几乎每天都要面对表级锁问题。
TRANSACTION 0, not started
mysql tables in use 97, locked 97
MySQL thread id 429, OS thread handle 0x2aff6ff59700, query id 24900 ec2-*-*-*-*.compute-1.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10631403, not started
MySQL thread id 321, OS thread handle 0x2af