MySQL 5.6.20 的一个实例运行（主要是）一个包含 InnoDB 表的数据库，在 1-4 分钟的持续时间内，所有更新操作偶尔会出现停顿，所有 INSERT、UPDATE 和 DELETE 查询都保持在“查询结束”状态。这显然是最不幸的。MySQL 慢查询日志甚至会记录具有疯狂查询时间的最琐碎的查询，其中数百个具有与解决停顿的时间点相对应的相同时间戳：
# Query_time: 101.743589 Lock_time: 0.000437 Rows_sent: 0 Rows_examined: 0
SET timestamp=1409573952;
INSERT INTO sessions (redirect_login2, data, hostname, fk_users_primary, fk_users, id_sessions, timestamp) VALUES (NULL, NULL, '192.168.10.151', NULL, 'anonymous', '64ef367018099de4d4183ffa3bc0848a', '1409573850');
并且设备统计数据显示增加，尽管在此时间范围内没有过多的 I/O 负载（在这种情况下，根据上述语句中的时间戳，更新在 14:17:30 - 14:19:12 停止）：
# sar -d
[...]
02:15:01 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
02:16:01 PM dev8-0 41.53 207.43 1227.51 34.55 0.34 8.28 3.89 16.15
02:17:01 PM dev8-0 59.41 137.71 …在查看对 MyISAM 表执行多次需要很长时间的特别烦人的查询时，我注意到 MySQL 似乎暴露了一种相当奇怪的 I/O 模式：当执行单个查询并且必须执行一个重要的查询时I/O 量（例如，对于表扫描或当缓存为空时，echo 3 > /proc/sys/vm/drop_caches因此需要首先从磁盘加载索引），底层块设备的队列大小接近值 1，性能极差仅 4-5 MB/s：
root@mysql-test:~# iostat -xdm 5 /dev/sda
Linux 3.2.0-40-generic (mysql-test) 04/30/2014 _x86_64_ (4 CPU)
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.14 24.82 18.26 88.79 0.75 4.61 102.56 2.83 26.39 19.29 27.85 2.46 26.31
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 69.29 151.52 72.73 5.31 0.59 53.95 1.21 5.39 …我正在尝试导入一个较长的 SQL 脚本（350 万行，大小为 1.5 GB），其中主要包含使用数据的短 INSERT INTO 语句，sqlcmd -E -d <database> -S 127.0.0.1 -i <scriptfile>并且它几乎爬行到停止（大约每秒 150 行）而没有推断出任何明显的SQL 服务器主机上的负载（所有 CPU 内核几乎空闲，磁盘吞吐量约为 200 KB/s）。
由于源文件位于 NFS 共享上，我首先怀疑这是罪魁祸首，但本地可用的相同脚本以相同的速度运行。
数据库基本上是空的，表是由完全相同的脚本创建的，没有触发器或其他花哨的东西——只是原始的，主要是数字或 varchar 数据。
SQLCMD 在等什么？有什么办法可以加快速度吗？
我们在更改 SQL 脚本文件中的数据方面的手段有限。数据由第三方为进口程序提供。我相信它最初是使用 Management Studio 2005 的“Script table as...”功能导出的。
由于文件庞大，编辑文件很乏味——使用普通文本编辑器，任何操作都会花费很长时间，尽管通过将两个文件复制到一起来完成“SET NOCOUNT ON”的准备——并且它带来了大约 50% 的加速。
由于文本编码 (Unicode-LE)，在不转换的情况下无法使用通用的 GNU textutils 集进行编辑（否则它可以很好地处理大文件） - 而且我不愿意转换，因为数据保真度问题可能会来吧。
因此，我对如何应用有关插入 BEGIN TRAN/COMMIT TRAN 块或将单个插入项转换为更大集合的建议有些困惑。
在虚拟化的 Ubuntu 12.04 上安装 MySQL 5.6.10 会出现大量内存占用。mysqld 进程在正常运行时间的几个小时内声明所有可用内存并强制主机交换：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16229 mysql 20 0 26.8g 21g 8736 S 42 93.4 37:23.22 mysqld
它曾经增长到 50 GB，因此大大超过了数据集本身：
Current InnoDB index space = 5.25 G
Current InnoDB data space = 23.07 G
通常，我可以通过发布 释放 ~ 3 GB FLUSH TABLES，尽管它比kill -9mysql 进程快得多，让它重新启动并为 InnoDB 运行恢复。使用的表几乎完全是 InnoDB，innodb_buffer_pool_size 已设置为 5 GB（将其设置为 16 GB 后会迅速耗尽可用物理内存并换出超过 18 GB）。
当系统正在交换时，我可以观察到相当高的“换出”计数器数字（vmstat 在突发期间显示约 1k 页/秒）并且几乎没有任何东西换回（每分钟几十页）。我首先怀疑内存泄漏，但到目前为止还没有发现任何支持这个假设的东西。
SHOW INNODB STATUS 表示缓冲池仅部分填充： …
我需要一些帮助来了解我在 MySQL 中的“慢查询”日志发生了什么。我已经设定
set global long_query_time=3
然而这是我在慢查询日志中看到的：
# Time: 120723 9:04:38
# User@Host: root[root] @ [111.111.111.205]
# Query_time: 0.017508 Lock_time: 0.000111 Rows_sent: 2884 Rows_examined: 9132
SET timestamp=1343027078;
SELECT [...]
# User@Host: root[root] @ [111.111.111.202]
# Query_time: 0.030282 Lock_time: 0.000102 Rows_sent: 0 Rows_examined: 12323
SET timestamp=1343027078;
SELECT [...]
# Time: 120723 9:04:41
# User@Host: root[root] @ [111.111.111.202]
# Query_time: 0.004416 Lock_time: 0.000104 Rows_sent: 18 Rows_examined: 6266
SET timestamp=1343027081;
SELECT [...]
# User@Host: root[root] @ hostname [111.111.111.199]
# Query_time: 0.029399 Lock_time: 0.000116 …在 MS SQL Server 2014 AlwaysOn AG 设置中，我想为给定的可用性组安排备份作业。最终目标是在同步的辅助节点上运行定期备份，最重要的是，不受特定辅助节点的可用性限制。
到目前为止，我看到的方法是使用 SQL Server 调度程序，在所有正在运行的实例上设置相同的作业，并将条件逻辑引入调度程序步骤，以确定角色是主要角色还是次要角色。由于以下几个原因，这对我的用例不起作用：
备份作业包括BACKUP LOG [...] WITH COMPRESSION, NOINIT, NOFORMAT每 15 分钟运行一次。
现在，我正在考虑创建一个绑定到相应 AG 的故障转移集群角色的集群计划任务，但想知道是否有更简单和简化的方法来实现这一点。