我最近更换了服务器，因为Joyent即将结束服务。但是对于rimuhosting的查询似乎需要更长的时间（2-6次）。但是行为存在巨大差异：大多数查询运行时间为.02秒或更短，然后有时这些完全相同的查询需要0.5秒或更长时间。两台服务器都运行mySQL和PHP（类似版本，但不是相同的确切数字）。
CPU的服务器负载为20-40％空闲。大多数内存正在使用，但他们告诉我这是正常的。技术支持告诉我它没有交换： 这就是它现在的样子:(虽然内存使用量最终会增加到接近最大值，就像上次一样） 内存：总计1513548k，使用1229316k，免费284232k，缓冲区63540k 交换：总计131064k，使用0k，免费131064k，缓存981420k
SQL max connections设置为400.
那么，为什么我有时会得到这些超慢的查询？
以下是查询的示例，有时为.01秒，有时大于1秒：
选择（！攻击AND（firstLoginDate＆gt; 1348703469））作为受保护，
id，universe.uid，universe.name AS obj_name，top，left，guilds.name as alliance，
rotate，what，player_data.first，player_data.last，
援助AS gid，（援助= 1892和援助＆gt; 0）因为，
舰队LIKE'％Turret％'AS炮塔，
startLeft，startTop，endLeft，endTop，duration，startTime，movetype，
移动，速度，防御，hp，lastAttack＆gt; 1349740269 AS ra FROM universe LEFT JOIN player_data ON universe.uid = player_data.uid
LEFT JOIN公会ON援助= guilds.gid
WHERE（扇区='21_82'或扇区='22_82'或扇区='21_83'或扇区='22_83'）或
（universe.uid = 1568425485 AND（升级= 1 OR建筑= 1））
是的，我确实在所有相应的列上都有索引。上面提到的所有3个表都是InnoDB表，这意味着它们只是行锁定而不是表锁定。
但这很有趣:(新服务器） Innodb_row_lock_time_avg 400获取行锁的平均时间，以毫秒为单位。 Innodb_row_lock_time_max 4,010获取行锁的最长时间（以毫秒为单位）。 Innodb_row_lock_waits 31必须等待行锁的次数。
为什么要获得行锁定需要这么长时间？ 我的旧服务器能够更快地获得行锁定： Innodb_row_lock_time_avg 26获取行锁的平均时间，以毫秒为单位。
这是新服务器： Opened_tables 5,500（仅用了2小时）已打开的表数。如果打开的表很大，则表缓存值可能太小。 表缓存256 表锁等待3,302（仅用了2小时）
这是旧服务器：
Opened_tables 420
表缓存64
这有意义吗？如果我增加表Cache会减轻一些事情吗？
注意：我在此服务器上有1.5 GB
这是解释
id select_type表类型possible_keys键key_len ref rows Extra
1 SIMPLE universe index_merge uidwhat，uid，uidtopleft，upgrade，building，sector sector，uid 38,8 NULL 116 using sort_union（sector，uid）;在哪里使用
1 SIMPLE player_data ref mainIndex mainIndex 8 jill_sp.universe.uid 1
1 SIMPLE公会eq_ref PRIMARY PRIMARY 8 jill_sp.player_data.aid 1