我在 drupal 7.14 和 MediaTemple 之间遇到了间歇性问题。具体来说，我遇到了这个错误：
PDOException：SQLSTATE [HY000]：一般错误：1205 锁等待超时超出；尝试重新启动事务：SELECT revision.order_number AS order_number、revision.revision_id AS revision_id、revision.revision_uid AS revision_uid、revision.mail AS mail、revision.status AS status、revision.log AS log、revision.revision_timestamp AS revision_timestamp、revision.revision_hostname AS revision_hostname、revision.data AS data、base.order_id AS order_id、base.type AS type、base.uid AS uid、base.created AS created、base.changed ASchanged、base.hostname AS hostname FROM {commerce_order} base INNER JOIN {commerce_order_revision} revision ON revision.revision_id = base.revision_id WHERE (base.order_id IN (:db_condition_placeholder_0)) FOR UPDATE； DrupalDefaultEntityController->load() 中的数组（[:db_condition_placeholder_0] => 75）（/nfs/c03/h01/mnt/81976/domains/wgsource.com/html/includes/entity.inc 的第 196 行）。
我被告知我的 MT 将表的类型更改为 MyISAM，并且他们和 drupal 之间存在问题。（见评论#23这里）。这并没有解决我的问题。我有一个网格容器，报告和配置如下。具体来说，我担心的是 MySQL 报告的第 39 行。我该怎么做才能解决这个问题？
MySQL 报告
1 MySQL 5.1.26-rc-5.1.26r uptime 0 0:9:1 Tue May 8 14:50:04 2012
2
3 __ Key _________________________________________________________________
4 Buffer used 0 of 24.00M %Used: 0.00
5 Current 4.49M %Usage: 18.71
6 Write hit 0.00%
7 Read hit 0.00%
8
9 __ Questions ___________________________________________________________
10 Total 23 0.0/s
11 Com_ 17 0.0/s %Total: 73.91
12 COM_QUIT 12 0.0/s 52.17
13 -Unknown 9 0.0/s 39.13
14 DMS 3 0.0/s 13.04
15 Slow 0 0/s 0.00 %DMS: 0.00
16 DMS 3 0.0/s 13.04
17 SELECT 3 0.0/s 13.04 100.00
18 REPLACE 0 0/s 0.00 0.00
19 DELETE 0 0/s 0.00 0.00
20 INSERT 0 0/s 0.00 0.00
21 UPDATE 0 0/s 0.00 0.00
22 Com_ 17 0.0/s 73.91
23 show_status 9 0.0/s 39.13
24 show_variab 3 0.0/s 13.04
25 admin_comma 2 0.0/s 8.70
26
27 __ SELECT and Sort _____________________________________________________
28 Scan 6 0.0/s %SELECT: 200.00
29 Range 0 0/s 0.00
30 Full join 0 0/s 0.00
31 Range check 0 0/s 0.00
32 Full rng join 0 0/s 0.00
33 Sort scan 0 0/s
34 Sort range 0 0/s
35 Sort mrg pass 0 0/s
36
37 __ Query Cache _________________________________________________________
38 Memory usage 17.07k of 12.00M %Used: 0.14
39 Block Fragmnt 100.00%
40 Hits 0 0/s
41 Inserts 1 0.0/s
42 Insrt:Prune 1:1 0/s
43 Hit:Insert 0.00:1
44
45 __ Table Locks _________________________________________________________
46 Waited 0 0/s %Total: 0.00
47 Immediate 19 0.0/s
48
49 __ Tables ______________________________________________________________
50 Open 8 of 1024 %Cache: 0.78
51 Opened 15 0.0/s
52
53 __ Connections _________________________________________________________
54 Max used 1 of 60 %Max: 1.67
55 Total 14 0.0/s
56
57 __ Created Temp ________________________________________________________
58 Disk table 2 0.0/s
59 Table 5 0.0/s
60 File 5 0.0/s
61
62 __ Threads _____________________________________________________________
63 Running 1 of 1
64 Cached 0 of 4 %Hit: 92.86
65 Created 1 0.0/s
66 Slow 0 0/s
67
68 __ Aborted _____________________________________________________________
69 Clients 0 0/s
70 Connects 0 0/s
71
72 __ Bytes _______________________________________________________________
73 Sent 18.31k 33.8/s
74 Received 1.49k 2.8/s
我的 SQL 配置
#
# Base Container
#
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
max_heap_table_size = 8M
skip-name-resolve
open_files_limit = 8000
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
bind-address = 0.0.0.0
# For compatibility
old_passwords = 1
back_log=20
max_connections=60
# due to mysql internally considering connections from 'user@host1' as a separate user from 'user@host2', max_user_connections is largely irrelevant in a clustered situation
max_user_connections=16
max_connect_errors=100000
key_buffer_size=24M
max_heap_table_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=256K
table_cache=1024
thread_cache_size=4
tmp_table_size=4M
join_buffer_size=4M
wait_timeout=60
thread_concurrency=4
innodb_file_per_table
max_allowed_packet = 16M
thread_stack = 128K
# query cache
query_cache_limit = 1048576
query_cache_size = 12M
query_cache_type = 1
# slow query log
log-slow-queries = /var/log/mysql/mysql-slow.log
long_query_time = 1
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[isamchk]
key_buffer = 16M
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
答案1
MT 工程师意识到这是一个问题，并提供了两种解决方法。第一种方法也是推荐的方法是：
1) 备份您的数据 2) 从您的帐户中删除 Drupal 3) 使用更新的一键安装重新安装 Drupal 4) 导入您的数据
第二种方法不一定是最好的解决方法，但已经过测试。注意：(mt) 不支持此方法。
1) 转储整个数据库 2) 转储变量表。“mysqldump -uUser -p db1234_drupal variable > db1234_drupal.variable.sql 3) 将“engine=INNODB”更改为“engine=MyISAM” 3. 重新导入表
*下面这样的语句现在可以工作了：MySQL 线程 ID 323367，查询 ID 16367943 205.186.184.26 db94731_blair 统计信息 SELECT 1 AS 表达式 FROM 变量变量 WHERE（（name = 'icl_manager_role'））FOR UPDATE