在 MS SQL Server 2014 AlwaysOn AG 设置中，我想为给定的可用性组安排备份作业。最终目标是让定期备份在同步的辅助节点上运行，最重要的是，不受特定辅助节点可用性的约束。
到目前为止我看到的方法是使用 SQL Server 调度程序，在所有正在运行的实例上设置相同的作业并将条件逻辑引入调度程序步骤以确定角色是主要角色还是次要角色。由于以下几个原因，这对我的用例不起作用：
备份作业BACKUP LOG [...] WITH COMPRESSION, NOINIT, NOFORMAT每 15 分钟运行一次。
现在，我正在考虑创建一个绑定到相应 AG 的故障转移集群角色的集群计划任务，但想知道是否有更简单和简化的方法来实现它。
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 2240.32 40.02 0.39 6.53 4.04 24.00
02:18:01 PM dev8-0 122.08 2816.99 1633.44 36.45 3.84 31.46 1.21 2.88
02:19:01 PM dev8-0 253.29 5559.84 3888.03 37.30 6.61 26.08 1.85 6.73
02:20:01 PM dev8-0 101.74 1391.92 2786.41 41.07 1.69 16.57 3.55 36.17
[...]
# sar
[...]
02:15:01 PM CPU %user %nice %system %iowait %steal %idle
02:16:01 PM all 15.99 0.00 12.49 2.08 0.00 69.44
02:17:01 PM all 13.67 0.00 9.45 3.15 0.00 73.73
02:18:01 PM all 10.64 0.00 6.26 11.65 0.00 71.45
02:19:01 PM all 3.83 0.00 2.42 24.84 0.00 68.91
02:20:01 PM all 20.95 0.00 15.14 6.83 0.00 57.07
通常情况下，我在 mysql 慢日志中注意到最旧的查询停止是插入到具有 VARCHAR 主键和全文搜索索引的大型（约 10 M 行）表中：
CREATE TABLE `files` (
`id_files` varchar(32) NOT NULL DEFAULT '',
`filename` varchar(100) NOT NULL DEFAULT '',
`content` text,
PRIMARY KEY (`id_files`),
KEY `filename` (`filename`),
FULLTEXT KEY `content` (`content`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
进一步的调查（即 SHOW ENGINE INNODB STATUS）表明，它确实总是使用全文索引对表进行更新，这导致了停顿。“SHOW ENGINE INNODB STATUS”的相应 TRANSACTIONS 部分具有类似以下两个的条目，用于最旧的正在运行的事务：
---TRANSACTION 162269409, ACTIVE 122 sec doing SYNC index
6 lock struct(s), heap size 1184, 0 row lock(s), undo log entries 19942
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_1" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_2" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_3" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_4" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_5" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_6" trx id 162269409 lock mode IX
---TRANSACTION 162269408, ACTIVE (PREPARED) 122 sec committing
mysql tables in use 1, locked 1
1 lock struct(s), heap size 360, 0 row lock(s), undo log entries 1
MySQL thread id 165998, OS thread handle 0x7fe0e239c700, query id 91208956 192.168.10.153 root query end
INSERT INTO files (id_files, filename, content) VALUES ('f19e63340fad44841580c0371bc51434', '1237716_File_70380a686effd6b66592bb5eeb3d9b06.doc', '[...]
TABLE LOCK table `vw`.`files` trx id 162269408 lock mode IX
因此，那里正在进行一些繁重的全文索引操作（doing SYNC index）停止对ANY表的所有 SUBSEQUENT更新。
undo log entries从日志来看， for 的数字似乎有点像doing SYNC index以约 150/s 的速度前进，直到达到 20,000，此时操作完成。
这个特定表的 FTS 大小令人印象深刻：
# du -c FTS_000000000000224a_00000000000036b9_*
614404 FTS_000000000000224a_00000000000036b9_INDEX_1.ibd
2478084 FTS_000000000000224a_00000000000036b9_INDEX_2.ibd
1576964 FTS_000000000000224a_00000000000036b9_INDEX_3.ibd
1630212 FTS_000000000000224a_00000000000036b9_INDEX_4.ibd
1978372 FTS_000000000000224a_00000000000036b9_INDEX_5.ibd
1159172 FTS_000000000000224a_00000000000036b9_INDEX_6.ibd
9437208 total
尽管这个问题也是由 FTS 数据量明显较小的表触发的，例如：
# du -c FTS_0000000000002467_0000000000003a21_INDEX*
49156 FTS_0000000000002467_0000000000003a21_INDEX_1.ibd
225284 FTS_0000000000002467_0000000000003a21_INDEX_2.ibd
147460 FTS_0000000000002467_0000000000003a21_INDEX_3.ibd
135172 FTS_0000000000002467_0000000000003a21_INDEX_4.ibd
155652 FTS_0000000000002467_0000000000003a21_INDEX_5.ibd
106500 FTS_0000000000002467_0000000000003a21_INDEX_6.ibd
819224 total
在这些情况下，失速的时间也大致相同。我在 bugs.mysql.com 上打开了一个错误，以便开发人员可以对此进行调查。
停顿的性质首先让我怀疑日志刷新活动是罪魁祸首，这篇关于 MySQL 5.5 的日志刷新性能问题的 Percona 文章描述了非常相似的症状，但进一步的事件表明 INSERT 操作到该数据库中的单个 MyISAM 表中也受到停顿的影响，所以这似乎不是一个仅限 InnoDB 的问题。
尽管如此，我还是决定每 10 秒跟踪一次“LOG”部分输出的Log sequence number值 Pages flushed up to。由于两个值之间的差值在减小，因此在停顿期间确实看起来冲洗活动正在进行：SHOW ENGINE INNODB STATUS
Mon Sep 1 14:17:08 CEST 2014 LSN: 263992263703, Pages flushed: 263973405075, Difference: 18416 K
Mon Sep 1 14:17:19 CEST 2014 LSN: 263992826715, Pages flushed: 263973811282, Difference: 18569 K
Mon Sep 1 14:17:29 CEST 2014 LSN: 263993160647, Pages flushed: 263974544320, Difference: 18180 K
Mon Sep 1 14:17:39 CEST 2014 LSN: 263993539171, Pages flushed: 263974784191, Difference: 18315 K
Mon Sep 1 14:17:49 CEST 2014 LSN: 263993785507, Pages flushed: 263975990474, Difference: 17377 K
Mon Sep 1 14:17:59 CEST 2014 LSN: 263994298172, Pages flushed: 263976855227, Difference: 17034 K
Mon Sep 1 14:18:09 CEST 2014 LSN: 263994670794, Pages flushed: 263978062309, Difference: 16219 K
Mon Sep 1 14:18:19 CEST 2014 LSN: 263995014722, Pages flushed: 263983319652, Difference: 11420 K
Mon Sep 1 14:18:30 CEST 2014 LSN: 263995404674, Pages flushed: 263986138726, Difference: 9048 K
Mon Sep 1 14:18:40 CEST 2014 LSN: 263995718244, Pages flushed: 263988558036, Difference: 6992 K
Mon Sep 1 14:18:50 CEST 2014 LSN: 263996129424, Pages flushed: 263988808179, Difference: 7149 K
Mon Sep 1 14:19:00 CEST 2014 LSN: 263996517064, Pages flushed: 263992009344, Difference: 4402 K
Mon Sep 1 14:19:11 CEST 2014 LSN: 263996979188, Pages flushed: 263993364509, Difference: 3529 K
Mon Sep 1 14:19:21 CEST 2014 LSN: 263998880477, Pages flushed: 263993558842, Difference: 5196 K
Mon Sep 1 14:19:31 CEST 2014 LSN: 264001013381, Pages flushed: 263993568285, Difference: 7270 K
Mon Sep 1 14:19:41 CEST 2014 LSN: 264001933489, Pages flushed: 263993578961, Difference: 8158 K
Mon Sep 1 14:19:51 CEST 2014 LSN: 264004225438, Pages flushed: 263993585459, Difference: 10390 K
并且在 14:19:11 点差已达到最低点，因此这里的冲水活动似乎已经停止，恰逢摊位结束。但是这些点让我认为 InnoDB 日志刷新是原因：
innodb_max_dirty_pages_pct填充水平开始的“异步”冲洗阶段之前 - 我没有看到
（数字([Log Sequence Number] - [Pages flushed up to]) / 1024来自SHOW ENGINE INNODB STATUS）
通过设置innodb_adaptive_flushing_lwm=1，这个问题似乎有所缓解，迫使页面清理器比以前做更多的工作。
error.log没有与摊位重合的条目。SHOW INNODB STATUS大约运行 24 小时后的摘录如下所示：
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 789330
OS WAIT ARRAY INFO: signal count 1424848
Mutex spin waits 269678, rounds 3114657, OS waits 65965
RW-shared spins 941620, rounds 20437223, OS waits 442474
RW-excl spins 451007, rounds 13254440, OS waits 215151
Spin rounds per wait: 11.55 mutex, 21.70 RW-shared, 29.39 RW-excl
------------------------
LATEST DETECTED DEADLOCK
------------------------
2014-09-03 10:33:55 7fe0e2e44700
[...]
--------
FILE I/O
--------
[...]
932635 OS file reads, 2117126 OS file writes, 1193633 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 17.00 writes/s, 1.20 fsyncs/s
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Main thread process no. 54745, id 140604272338688, state: sleeping
Number of rows inserted 528904, updated 1596758, deleted 99860, read 3325217158
5.40 inserts/s, 10.40 updates/s, 0.00 deletes/s, 122969.21 reads/s
所以，是的，数据库确实有死锁，但它们很少见（“最新”在读取统计数据前大约 11 小时处理）。
我尝试在一段时间内跟踪“SEMAPHORES”部分的值，特别是在正常操作和停顿期间（我编写了一个小脚本检查 MySQL 服务器的进程列表并在日志输出中运行几个诊断命令以防万一明显的失速）。由于这些数字是在不同的时间范围内采用的，因此我将结果标准化为事件/秒：
normal stall
1h avg 1m avg
OS WAIT ARRAY INFO:
reservation count 5,74 1,00
signal count 24,43 3,17
Mutex spin waits 1,32 5,67
rounds 8,33 25,85
OS waits 0,16 0,43
RW-shared spins 9,52 0,76
rounds 140,73 13,39
OS waits 2,60 0,27
RW-excl spins 6,36 1,08
rounds 178,42 16,51
OS waits 2,38 0,20
我不太确定我在这里看到了什么。大多数数字下降了一个数量级 - 可能是由于更新操作停止，“互斥旋转等待”和“互斥旋转轮数”都增加了 4 倍。
进一步调查，互斥锁列表 ( SHOW ENGINE INNODB MUTEX) 在正常操作和停顿期间列出了大约 480 个互斥锁条目。我已经启用innodb_status_output_locks，看看它是否会给我更多的细节。
（我已经对其中的大多数进行了修补，但没有取得明确的成功）：
mysql> show global variables where variable_name like 'innodb_adaptive_flush%';
+------------------------------+-------+
| Variable_name | Value |
+------------------------------+-------+
| innodb_adaptive_flushing | ON |
| innodb_adaptive_flushing_lwm | 1 |
+------------------------------+-------+
mysql> show global variables where variable_name like 'innodb_max_dirty_pages_pct%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_max_dirty_pages_pct | 50 |
| innodb_max_dirty_pages_pct_lwm | 10 |
+--------------------------------+-------+
mysql> show global variables where variable_name like 'innodb_log_%';
+-----------------------------+-----------+
| Variable_name | Value |
+-----------------------------+-----------+
| innodb_log_buffer_size | 8388608 |
| innodb_log_compressed_pages | ON |
| innodb_log_file_size | 268435456 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
+-----------------------------+-----------+
mysql> show global variables where variable_name like 'innodb_double%';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| innodb_doublewrite | ON |
+--------------------+-------+
mysql> show global variables where variable_name like 'innodb_buffer_pool%';
+-------------------------------------+----------------+
| Variable_name | Value |
+-------------------------------------+----------------+
| innodb_buffer_pool_dump_at_shutdown | OFF |
| innodb_buffer_pool_dump_now | OFF |
| innodb_buffer_pool_filename | ib_buffer_pool |
| innodb_buffer_pool_instances | 8 |
| innodb_buffer_pool_load_abort | OFF |
| innodb_buffer_pool_load_at_startup | OFF |
| innodb_buffer_pool_load_now | OFF |
| innodb_buffer_pool_size | 29360128000 |
+-------------------------------------+----------------+
mysql> show global variables where variable_name like 'innodb_io_capacity%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| innodb_io_capacity | 200 |
| innodb_io_capacity_max | 2000 |
+------------------------+-------+
mysql> show global variables where variable_name like 'innodb_lru_scan_depth%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_lru_scan_depth | 1024 |
+-----------------------+-------+
SET GLOBAL query_cache_size=0innodb_log_buffer_size128Minnodb_adaptive_flushing,innodb_max_dirty_pages_pct和各自的_lwm值（在我更改之前它们被设置为默认值）innodb_io_capacity(2000) 和innodb_io_capacity_max(4000)innodb_flush_log_at_trx_commit = 2noop或deadline
伙计们，
我正在运行我们生产数据库的副本作为 SQL Server Reporting Services 实例的后端。该副本正在从事务日志中更新，这些日志经常（每小时）使用RESTORE DATABASE WITH NORECOVERY/用于备份目的WITH STANDBY。我显然不能使用内置的事务日志传送设施，因为数据库已经被BACKUP LOGged 并且尝试使用日志传送会破坏两种机制的日志链。
但是我需要一些方法来监控我的副本是否是最新的，最好不要更改原始数据库的架构或数据。我的第一种方法是使用检索最近的日志备份的最后一个 LSNRESTORE HEADERONLY FROM DISK并将其与我的副本实例的 LSN 进行比较。但是我很难找到一个能够匹配结果的 LSN RESTORE HEADERONLY- 我在sys.database_files中看到的似乎完全不同。
我在哪里可以找到匹配的 LSN？
在查看一个特别烦人的 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 7.84 0.29 4.39 98.51
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 153.06 144.29 174.69 4.96 1.36 40.54 1.39 4.36 8.91 0.60 3.15 100.49
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 105.75 150.92 109.03 4.53 0.85 42.41 1.29 4.96 8.15 0.54 3.90 101.36
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 48.89 156.36 51.72 5.28 0.76 59.38 1.28 6.16 8.02 0.55 4.77 99.23
虽然 150 IOPS 只是给定配置中的单个磁盘在随机 I/O 方面能够提供的，但结果仍然让我感到惊讶，因为我希望 MySQL 能够运行异步 I/O 进行读取并获取一个同时处理大量块而不是一个一个地读取和评估它们，有效地忽略了 RAID 配置中可用的并行化增益。什么设计决策或配置选项对此负责？这是特定于平台的问题吗？
虽然我已经用大型 MyISAM 表对此进行了测试，但我发现将相同的表转换为 InnoDB 会产生类似的效果（虽然还不错，示例查询仍然需要 20-30 秒，其中大部分时间都花在读取磁盘上在我重新启动 mysql 守护程序后，队列长度为 1)，因此缓冲池为空。我还验证了同样的问题在 5.6 GA 和当前的 5.7 里程碑 14 上仍然存在——只要我使用单个查询线程，MySQL 似乎无法并行化查询处理所需的 I/O 操作。
根据请求，有关该场景的一些其他详细信息。可以通过多种查询类型观察到该行为。我随意选择了一个进行进一步测试，内容有点像这样：
SELECT herp.id, herp.firstname, herp.lastname, derp.label, herp.email,
(SELECT CONCAT(label, " (", zip_code, " ", city,")" ) FROM subsidiaries WHERE subsidiaries.id=herp.subsidiary_id ) AS subsidiary,
(SELECT COUNT(fk_herp) from herp_missing_data WHERE fk_herp=herp.id) AS missing_data
FROM herp LEFT JOIN derp ON derp.id=herp.fk_derp
WHERE (herp.fk_pools='123456') AND herp.city LIKE '%Some City%' AND herp.active='yes'
ORDER BY herp.id desc LIMIT 0,10;
我知道它有一些优化空间，但出于多种原因我决定将其留在那儿，并专注于为我看到的意外 I/O 模式寻找一般解释。
使用过的表中确实有一堆数据：
mysql> select table_name, engine, table_rows, data_length, index_length from information_schema.tables WHERE tables.TABLE_SCHEMA = 'mydb' and tables.table_name in ( 'herp', 'derp', 'missing_data', 'subsidiaries');
+-------------------------+--------+------------+-------------+--------------+
| table_name | engine | table_rows | data_length | index_length |
+-------------------------+--------+------------+-------------+--------------+
| derp | MyISAM | 14085 | 1118676 | 165888 |
| herp | MyISAM | 821747 | 828106512 | 568057856 |
| missing_data | MyISAM | 1220186 | 15862418 | 29238272 |
| subsidiaries | MyISAM | 1499 | 6490308 | 103424 |
+-------------------------+--------+------------+-------------+--------------+
4 rows in set (0.00 sec)
现在，当我在这些表上运行上面的查询时，我得到的执行时间超过 1 分钟，而系统显然一直忙于使用单个线程从磁盘读取数据。
示例查询执行的配置文件（在此示例中耗时 1 分 9.17 秒）如下所示：
mysql> show profile for query 1;
+--------------------------------+-----------+
| Status | Duration |
+--------------------------------+-----------+
| starting | 0.000118 |
| Waiting for query cache lock | 0.000035 |
| init | 0.000033 |
| checking query cache for query | 0.000399 |
| checking permissions | 0.000077 |
| checking permissions | 0.000030 |
| checking permissions | 0.000031 |
| checking permissions | 0.000035 |
| Opening tables | 0.000158 |
| init | 0.000294 |
| System lock | 0.000056 |
| Waiting for query cache lock | 0.000032 |
| System lock | 0.000116 |
| optimizing | 0.000063 |
| statistics | 0.001964 |
| preparing | 0.000104 |
| Sorting result | 0.000033 |
| executing | 0.000030 |
| Sending data | 2.031349 |
| optimizing | 0.000054 |
| statistics | 0.000039 |
| preparing | 0.000024 |
| executing | 0.000013 |
| Sending data | 0.000044 |
| optimizing | 0.000017 |
| statistics | 0.000021 |
| preparing | 0.000019 |
| executing | 0.000013 |
| Sending data | 21.477528 |
| executing | 0.000070 |
| Sending data | 0.000075 |
| executing | 0.000027 |
| Sending data | 45.692623 |
| end | 0.000076 |
| query end | 0.000036 |
| closing tables | 0.000109 |
| freeing items | 0.000067 |
| Waiting for query cache lock | 0.000038 |
| freeing items | 0.000080 |
| Waiting for query cache lock | 0.000044 |
| freeing items | 0.000037 |
| storing result in query cache | 0.000033 |
| logging slow query | 0.000103 |
| cleaning up | 0.000073 |
+--------------------------------+-----------+
44 rows in set, 1 warning (0.00 sec)
在虚拟化 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 表示缓冲池仅被部分填满：
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 5365825536; in additional pool allocated 0
Dictionary memory allocated 2558496
Buffer pool size 320000
Free buffers 173229
Database pages 142239
Old database pages 52663
Modified db pages 344
Pending reads 1
Pending writes: LRU 0, flush list 1 single page 0
Pages made young 34, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 141851, created 387, written 41126
81.16 reads/s, 0.00 creates/s, 0.39 writes/s
Buffer pool hit rate 998 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 142239, unzip_LRU len: 0
I/O sum[0]:cur[464], unzip sum[0]:cur[0]
服务器总共有 80-90 个连接，其中大部分被 SHOW PROCESSLIST 报告为处于“睡眠”状态。
内存敏感选项集是
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
max_connections = 1000
innodb_file_format = Barracuda
innodb_buffer_pool_size = 5000M
innodb_log_file_size = 256M
innodb_flush_method = O_DIRECT
query_cache_limit = 1M
query_cache_size = 256M
join_buffer_size = 256k
tmp_table_size = 2M
max_heap_table_size = 64M
Tuning-primer.sh 脚本计算内存使用的合理值：
MEMORY USAGE
Max Memory Ever Allocated : 5.27 G
Configured Max Per-thread Buffers : 1.92 G
Configured Max Global Buffers : 5.15 G
Configured Max Memory Limit : 7.07 G
Physical Memory : 22.98 G
Max memory limit seem to be within acceptable norms
Binlog 已启用，并且主机连接了一个复制从属设备（尽管当时的结果并没有太大的不同，但情况并非如此）。Innodb_file_per_table 在 5.6 中默认启用，数据库总共托管约 1,300 个表。
我必须用什么方法来确定明显无限增长的可能原因？
在阅读了“MySQL 如何使用内存”之后，我怀疑临时表可能是罪魁祸首。如果由于某种原因没有正确释放它们，它们可能会很快积累。查询数据库的应用程序会发出大量嵌套的、复杂的查询，因此根据引用的文档，临时表将被大量使用。我尝试检查在mysqld达到〜20 GB时终止/重置现有（空闲）连接是否会显着减少内存使用量 - 它不会，因此这与连接状态无关，或者内存以某种方式从那里泄漏不受关闭连接的影响。
我将如何验证内存中的临时表是否占用了大量内存？STATUS 变量和 INFORMATION_SCHEMA 似乎没有此信息。
MySQL 的内存使用似乎很难调试 - 可用的计数器似乎没有占到我看到的大部分使用情况。不过，我可能会遗漏一些东西。
我还有一个基于 MyISAM 的复制从属连接到 InnoDB 主控，具有类似的（只读）负载 - 它没有显示任何内存使用过多的迹象（mysqld RSS 持续 < 1GB），所以问题似乎是特定于InnoDB 配置。
我试图用它log_queries_not_using_indexes = 1来查找在 MySQL 服务器上没有以最佳方式执行的查询。但是，我发现生成的日志文件的价值相当有限。显然，只要优化器真的决定不在 WHERE 子句中使用索引作为标准，就会记录查询。如果它们确实没有与过滤列匹配的索引，则不会。
所以给定一个具有以下结构的表
CREATE TABLE `test` (
`id_test` int(11) NOT NULL AUTO_INCREMENT,
`some_text` varchar(255) DEFAULT NULL,
`some_more_text` text,
PRIMARY KEY (`id_test`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
由于不使用索引，查询SELECT id_test from test where id_test != 69将被记录到慢速日志中（优化器已决定表扫描更有效，因为使用索引不会赢得太多）但SELECT id_test from test where id_test = 69不会。
由于索引存在，我希望后一种查询的行为在第一种情况下也是如此。照原样，它使故障排除丢失的索引相当烦人。关于如何解决这个问题的想法非常感谢。
根据MySQL 的复制文档，可以设置从 InnoDB 源表到 MyISAM 目标表的复制。不幸的是，文档几乎没有谈到缺点、数据一致性影响（除了 CASCADE 极端案例）和启用这种复制配置的推荐设置。因此，关于此设置，我想到了一些问题：
ALTER TABLE blah ENGINE=InnoDB在主服务器上运行的语句传播到从服务器？ALTER TABLE blah ENGINE=MyISAM上slave，这样可行吗？
我需要一些帮助来了解我在 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 Rows_sent: 0 Rows_examined: 12323
SET timestamp=1343027088;
SELECT [...]
# Time: 120723 9:04:53
# User@Host: root[root] @ [111.111.111.201]
# Query_time: 0.004470 Lock_time: 0.000080 Rows_sent: 0 Rows_examined: 6248
SET timestamp=1343027093;
SELECT [...]
# Time: 120723 9:04:55
# User@Host: root[root] @ [111.111.111.198]
# Query_time: 0.042627 Lock_time: 0.000087 Rows_sent: 0 Rows_examined: 0
use [...];
SET timestamp=1343027095;
UPDATE [...]
# User@Host: root[root] @ [111.111.111.198]
# Query_time: 0.029115 Lock_time: 0.000124 Rows_sent: 0 Rows_examined: 0
Query_time 中的时间明显低于我之前指定的 3 秒。为什么？错过的时间在哪里？
MySQL 5.1.41、Ubuntu 10.04
我正在尝试导入一个较长的 SQL 脚本（350 万行，大小为 1.5 GB），其中主要包含带有数据的短 INSERT INTO 语句，sqlcmd -E -d <database> -S 127.0.0.1 -i <scriptfile>并且它几乎停止（大约每秒 150 行）而没有推断出任何明显的SQL server 主机上的负载（所有 CPU 内核几乎处于空闲状态，磁盘吞吐量约为 200 KB/s）。
由于源文件位于 NFS 共享上，我首先怀疑这是罪魁祸首，但本地可用的相同脚本以相同的速度运行。
数据库基本上是空的，表是由相同的脚本创建的，没有触发器或其他花哨的东西——只是原始的，主要是数字或 varchar 数据。
SQLCMD 还在等什么？有什么办法可以加快速度吗？
我们在更改 SQL 脚本文件中的数据方面受到限制。数据由第三方提供用于导入程序。我相信它最初是使用 Management Studio 2005“脚本表作为...”功能导出的。
由于庞大的文件大小，编辑文件很乏味 - 任何操作都需要使用普通文本编辑器，尽管预先设置“SET NOCOUNT ON”是通过将两个文件复制在一起完成的 - 它带来了大约 50% 的加速。
由于文本编码 (Unicode-LE)，如果不进行转换，就不可能使用通用的 GNU textutils 集（否则它可以很好地处理大文件）进行编辑 - 而且由于数据保真度问题可能会导致我不愿意转换来吧。
因此，我对如何应用有关插入 BEGIN TRAN/COMMIT TRAN 块或将单个插入转换为更大集合的建议感到有些困惑。