正在选择查询时无法写入 mysql 数据库

Question

在 InnoDB 上运行 Mysql 5.1.57，并且存在数据库锁定问题。

我有两个单独的会话连接到单个数据库 MySQL。在第一个会话中，我在表 A 上运行了一个很长的 SELECT 查询（技术上是一个慢速查询）。然后在另一个连接上，我在表 B 上运行了一个小的 UPDATE 查询。

编辑：如本主题底部所述，当表/查询完全位于不同的数据库中时也会出现此问题，并且不限于表/查询位于同一数据库中。

由于某种原因，在长选择查询完成之前，表 B 上的更新不会完成，就好像它们在同一个连接上一样。此外，“PROCESS LIST”将第二个查询显示为“正在释放项目”，同时它正在等待执行。

是否有任何设置或配置问题会导致这些查询按顺序运行而不是同时运行？

在此先感谢您的帮助。

表A

CREATE TABLE `history` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) DEFAULT NULL,
  `log` text NOT NULL,
  `created_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `user_id_idx` (`user_id`),
  CONSTRAINT `history_user_id_user_id` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=364398 DEFAULT CHARSET=utf8

表B

CREATE TABLE `client` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `root_id` int(11) DEFAULT NULL,  
  `salesperson_id` int(11) DEFAULT NULL,
  `name` varchar(127) DEFAULT NULL,
  `notes` text,
  `created_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `root_id_idx` (`root_id`),
  KEY `salesperson_id_idx` (`salesperson_id`),
  CONSTRAINT `client_root_id_client_id` FOREIGN KEY (`root_id`) REFERENCES `client` (`id`) ON DELETE CASCADE,
  CONSTRAINT `client_salesperson_id_user_id` FOREIGN KEY (`salesperson_id`) REFERENCES `user` (`id`) ON DELETE SET NULL
) ENGINE=InnoDB AUTO_INCREMENT=757 DEFAULT CHARSET=utf8

查询 1：

SELECT * 
FROM `history` 
WHERE log LIKE '%a%' ORDER BY log ASC LIMIT 0, 20000; // (fictitious query to replicate the issue) 

运行大约需要 10 秒

查询 2：

UPDATE `client` SET name = 'Test Name' WHERE id = 24; // hangs until query 1 is complete

MySQL 版本信息

+---------------+-------------- -------+
| 变量名 | 价值 |
+---------------+-------------- -------+
| innodb_version | 1.0.16 |
| 协议版本| 10 |
| 版本| 5.1.57-日志 |
| version_comment | MySQL 社区服务器 (GPL) |
| version_compile_machine | x86_64 |
| version_compile_os | 未知-linux-gnu |
+---------------+-------------- -------+

注意：这是一个 Amazon RDS 服务器 (m1.large)

全局 InnoDB 变量

+---------------------------------+--------------- ---------+
| 变量名 | 价值 |
+---------------------------------+--------------- ---------+
| have_innodb | 是 |
| ignore_builtin_innodb | 开 |
| innodb_adaptive_flushing | 开 |
| innodb_adaptive_hash_index | 开 |
| innodb_additional_mem_pool_size | 2097152 |
| innodb_autoextend_increment | 8 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_size | 5882511360 |
| innodb_change_buffering | 插入|
| innodb_checksums | 开 |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | /rdsdbdata/db/innodb |
| innodb_doublewrite | 开 |
| innodb_fast_shutdown | 1 |
| innodb_file_format | 羚羊 |
| innodb_file_format_check | 梭鱼 |
| innodb_file_per_table | 开 |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_flush_method | O_DIRECT |
| innodb_force_recovery | 0 |
| innodb_io_capacity | 200 |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | 关闭 |
| innodb_log_buffer_size | 8388608 |
| innodb_log_file_size | 134217728 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | /rdsdbdata/log/innodb |
| innodb_max_dirty_pages_pct | 75 |
| innodb_max_purge_lag | 0 |
| innodb_mirrored_log_groups | 1 |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 0 |
| innodb_open_files | 300 |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | 关闭 |
| innodb_spin_wait_delay | 6 |
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | 开 |
| innodb_stats_sample_pages | 8 |
| innodb_strict_mode | 关闭 |
| innodb_support_xa | 开 |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | 开 |
| innodb_thread_concurrency | 0 |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_sys_malloc | 开 |
| innodb_version | 1.0.16 |
| innodb_write_io_threads | 4 |
+---------------------------------+--------------- ---------+

连接变量

+----------------------+-------+
| 变量名 | 价值 |
+----------------------+-------+
| max_connections | 第623话
| max_user_connections | 0 |
+----------------------+-------+

问题在不同的数据库中仍然存在

进一步的测试表明，我们可以在一个完全不同的数据库上重新创建这个问题，从而消除任何有关表锁定的问题。为了重现这一点，我们在一个数据库中设置表 A/查询 1，在一个完全独立的数据库（在同一台服务器上）中设置表 B/查询 2。当查询 1 正在运行时，查询 2 在完成之前等待 #1 完成。

这让我相信有一些服务器范围的东西（操作系统级别的文件锁定？）导致了这个问题，与任何一个数据库或表无关。有任何想法吗？

用户授权

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS,
REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW,
CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.*
TO 'username'@'%' IDENTIFIED BY PASSWORD 'password' WITH GRANT OPTION

Answer 1

经过一周处理 AWS 支持并运行多个基准测试后，问题的答案是，RDS 通过其操作系统/文件系统设置了 I/O 上限，禁止大型查询正确处理此类场景。

我们无法在标准 LAMP 堆栈上重现此问题，即使在微型实例上也是如此。在我们别无选择后，我们向 AWS 寻求支持。

我们提供了准确的数据集，设置了一个 RDS 实例供 AWS 进行测试，并提供了如何重现问题的准确说明。RDS 能够重现该问题，经过测试后，他们得出了以下答案：

“RDS 已经对此进行了调查，它基本上耗尽了磁盘 I/O（写入），从而导致第二个查询变慢。” ...“MySQL 为此使用临时表，这会导致数据库执行许多写入操作，尽管是 SELECT。”

因此，实际上，由于这是 RDS 产生的瓶颈，因此这种情况可能只会发生在 RDS 上，而不是常规的 MySQL 安装上。

底线：如果您遇到此问题，请转移到不同的数据库设置。