我有一个关于同时使用 MyISAM 和 InnoDB 的 MySQL 数据库的逻辑备份的问题。
该mysqldump实用程序支持以下两个选项：
--single-transaction - 通过在单个事务中转储所有表来创建一致的快照。仅适用于存储在支持多版本的存储引擎中的表（目前只有 InnoDB 支持）[...] 选项自动关闭 --lock-tables。
-x, --lock-all-tables - 锁定所有数据库中的所有表。这是通过在整个转储期间获取全局读锁来实现的。自动关闭 --single-transaction 和 --lock-tables 。
对于 InnoDB，我们需要 --single-transaction
对于 MyISAM，我们需要 - 锁定表或锁定所有表（以防我们需要跨数据库一致性）。
那么，混合数据库（同时使用 MyISAM 和 InnoDB 引擎的数据库）应该如何备份？
编辑：
为了澄清，这个问题可以重新表述如下：
lock-[all-]tables 选项是否保证 InnoDB 表的一致备份？
我是Moodle站点的管理员，该站点的用户表已损坏并且无法使用。
幸运的是，一个简单的方法REPAIR TABLE mdl_user使它再次工作。问题是我不知道为什么它实际上崩溃并使其无法使用，我想确保下次我有更好的准备。
我不是一个经验丰富的 DBA——我只是一个做很多事情的开发人员，所以请耐心等待。
我可以只恢复备份，但我想有办法防止崩溃。
这些表是 utf8_general_ci 并使用 MyISAM。
为什么 MySQL 表会崩溃？我能做些什么来防止这种情况发生？
我正在插入一个具有 5 个属性和 1000 行的简单小表。
我观察到当引擎是 INNODB 时，每个插入需要 0.03 - 0.05 秒。我将引擎更改为 MYISAM，然后插入速度更快。它需要 0.001 - 0.003。
问题是什么。默认情况下 innodb_flush_log_trx_commit = 1。我就是这个设置。这是我的 innodb 设置。
innodb_log_buffer_size : 1MB
innodb_log_file_size : 5MB
innodb_buffer_pool_size: 8MB
innodb_flush_log_trx_commit = 1
mysql> desc table ;
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id | int(10) | YES | | NULL | |
| count | int(10) | YES | | NULL | |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.00 …在 Debian Linux 服务器上，托管许多 PHP/MySQL 网站（图片库），有时我有“很多”文件，例如/tmp/#sql_6405_58.MYD.
例如今天：
[2012-12-15 15:18:11] /tmp/#sql_6405_6.MYD : 88MB
[2012-12-15 15:18:11] /tmp/#sql_6405_3.MYD : 22MB
[2012-12-15 15:18:11] /tmp/#sql_6405_4.MYD : 138MB
[2012-12-15 15:18:11] /tmp/#sql_6405_10.MYD : 88MB
...
[2012-12-15 15:18:11] /tmp/#sql_6405_9.MYD : 15MB
[2012-12-15 15:18:11] /tmp/#sql_6405_65.MYD : 49MB
[2012-12-15 15:18:11] /tmp/#sql_6405_44.MYD : 69MB
（同时 59 个文件，超过 6GB...是的，我在 /tmp 中监控大文件）
不幸的是，/tmp它在同一个分区上/，它暂时中断了 Web 服务器，因为/我想是满的。然后文件消失，服务器恢复正常。
所有文件名都遵循该#sql_6405_*.MYD模式。我想了解哪个 MySQL 操作意味着这么多临时文件。我在这台服务器上有大约 2000 个数据库。是否有可能知道涉及哪个数据库？
我的数据库速度变慢了。phpMyAdmin 中的分析器建议我OPTIMIZE TABLE在我的表上运行。
但在这样做之前，我（当然）想知道表中的数据是否会发生任何事情，或者此操作是否完全无害。
使用时我应该考虑利弊OPTIMIZE TABLE吗？索引和主键会保持不变吗？数据库中是否有优化后会变慢的区域？
我正在寻求帮助以了解执行以下命令行时会发生什么：
root@prodn$ service mysqld stop
是的，它会关闭 MySQL 服务器，因此在服务再次启动之前无法再访问它。但是，更具体地说，服务停止时是否还会发生其他情况？请原谅我的新手，但是当mysqld重新启动时，是否意味着日志已刷新、一些内存已释放、缓存已清空等？
我问的原因如下：
我们的数据仓库 DB 是 MySQL DB，在过去的 4 个月中，平均需要 8.5 小时。
上周三，我已经停止了 mysql 服务，然后在 30 分钟后重新启动了它。从那时起，我开始注意到整体性能的巨大改进——SELECT/INSERT/UPDATE/DELETE 过程更加高效。DW 以相同数量的数据行提前近 4 小时完成
然而，随着时间的流逝，15-20 分钟不知何故被添加到完成时间。所以，我怀疑我可能必须每周重新启动服务。
这种行为有解释吗？我不知道还有哪些其他问题是相关的，但是知道mysqld服务重新启动时会发生什么会很棒。
任何人都可以对此有所了解吗？
我对数据库管理知之甚少，但我必须处理我网站上的一些非常大的表。
该服务器具有 64GB 内存和 Intel Core i7-3820 (4 x 3600 MHz)。它所做的大部分事情都是 MySQL。我使用一半 MyISAM 和一半 InnoDB 表。
我在 MyISAM 中有几个表，有数十亿行。每天我都有一个脚本禁用键，再添加几百万行，然后再次启用键。这ALTER TABLE... ENABLE KEYS会导致服务器基本上停止几个小时。任何使用 MySQL 的网站都不会加载，即使它们根本不访问正在更改的表。
还请告诉我如何设置 my.cnf 文件以解决此问题并优化以尽快重建这些索引。有人告诉我增加key_buffer_size，但我不确定这是否好，因为每个人似乎都有不同的意见..？目前它看起来像这样：
[client]
port = 3306
socket = /var/lib/mysql/mysql.sock
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-external-locking
max_allowed_packet = 512M
table_open_cache = 1024
sort_buffer_size = 128M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 24G
thread_cache_size = 12
query_cache_size = 256M
thread_concurrency = 16
log-bin=mysql-bin
binlog_format=mixed
server-id = 1
innodb_file_per_table = 1
table_cache …我们已经让数据库挂了两次并试图找到原因。
show processlist
Waiting for global read lock | INSERT INTO {myisam_table} ...
在这里，磁盘空间已满，所以我们认为问题在给它一些后就解决了，但第二天中午它又挂了：
show processlist
Waiting for table level lock | UPDATE {myisam_table} ...
是什么原因造成的？
Mysql 默认引擎：InnoDB。
数据库混合了带有 MyISAM 和 InnoDB 引擎的表。
日志贴在这里：
http://arturito.net/2013/08/28/mysql-waiting-for-table-level-lock-errors/
在查看对 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 …我正在研究跟踪使用时间的分析系统的架构，并且需要查看特定日期范围内的总使用时间。
举一个简单的例子，这种类型的查询会经常运行：
select sum(diff_ms) from writetest_table where time_on > ("2015-07-13 15:11:56");
此查询通常需要大约 7 秒的时间在一个人口密集的表上。它有大约 3500 万行，MyISAM on MySQL 在 Amazon RDS (db.m3.xlarge) 上运行。
去掉 WHERE 子句使查询只需要 4 秒，添加第二个子句 (time_off > XXX) 增加了 1.5 秒，使查询时间达到 8.5 秒。
因为我知道这些类型的查询会很常见，所以我想优化一些东西，使它们更快，理想情况下低于 5 秒。
我首先在 time_on 上添加一个索引，虽然这大大加快了 WHERE "=" 查询，但它对 ">" 查询没有影响。有没有办法创建一个可以加速 WHERE ">" 或 "<" 查询的索引？
或者如果对此类查询的性能有任何其他建议，请告诉我。
注意：我使用“diff_ms”字段作为非规范化步骤（它等于 time_off - time_on），它将聚合性能提高了大约 30%-40%。
我正在使用以下命令创建索引：
ALTER TABLE writetest_table ADD INDEX time_on (time_on) USING BTREE;
在原始查询上运行“explain”（使用“time_on >”）表示 time_on 是一个“possible_key”，而 select_type 是“SIMPLE”。“额外”列显示“使用位置”，“类型”为“全部”。添加索引后，该表显示“time_on”是“MUL”键类型，这似乎是正确的，因为同一时间可以出现两次。
这是表架构：
CREATE TABLE `writetest_table` (
`id` …