在此处记录此错误和解决方案，以防它对任何人有所帮助。我们在 Amazon RDS 上有一个 MYSQL 8 数据库。下面的 group by 过去在 Mysql 5.7 上工作得很好，但是
1022 Can't write; duplicate key in table '/rdsdbdata/tmp/#sqlf80_1656bc_0'
一旦我们升级到 Mysql 8，它就开始出错了。
GROUP BY DATE_FORMAT(CONCAT(YEAR(performance_stats_date),'-',
MONTH(performance_stats_date),'-',DAY(performance_stats_date)),
'%Y-%m-%d')
我们最近尝试设置innodb_undo_tablespaces=2我们的 mysql 5.7 服务器。但在重新启动期间，服务器返回：
[ERROR] InnoDB: Expected to open 2 undo tablespaces but was able to find only 0 undo tablespaces. Set the innodb_undo_tablespaces parameter to the correct value and retry. Suggested value is 0
事实证明这已经记录在案：“ innodb_undo_tablespaces 的数量必须在初始化 InnoDB 之前设置。尝试使用比您首次创建数据库时指定的更多数量的撤消表空间重新启动 InnoDB 将导致启动失败和错误说明 InnoDB 没有找到预期数量的 undo 表空间。 ”
“首先创建数据库”是什么意思？该文档是否意味着在服务器中没有数据库的情况下全新安装 mysql？有没有办法绕过这个要求？
即使我们从第一天开始就使用“innodb_file_per_table = 1”。ibdata 文件仍在继续增长。我们数据库的总大小约为 800GB，而 ibdata 文件目前约为 50GB。我们所有的表都是 innodb。
当我们使用 innodb_file_per_table 时，它如何增长？
可能是 blob、mediumtext 或这些类型的列？
考虑到我们已经使用了 innodb_file_per_table，有没有办法缩小这个？
在具有自定义数据目录的 Centos 服务器上启动 mysql 时，您可能会收到类似于以下内容的错误：
2014-10-15 10:23:56 17081 [Warning] Can't create test file /database/mysql/localhost.lower-test
我们使用 Percona 的 pt-table-checksum 进行 MySQL 复制完整性检查。
是否可以使用某种配置文件传递部分或全部选项？
例如，我们可以在文件中写入我们想要检查的表列表吗？
我了解手册没有谈到这样的文件：http ://www.percona.com/doc/percona-toolkit/2.1/pt-table-checksum.html
在 MySQL 中设置复制之前，首先需要将数据传输到从站。
由于 MyISAM 表可以复制为文件。可以将 MyISAM 文件 .myd .myi .frm 复制到从站吗？这足以开始复制吗？
MySQL 5.5 引入了“列分区”。
http://dev.mysql.com/doc/refman/5.5/en/partitioning-columns.html
我试图更好地理解当两列单独重要时它是如何工作的。
假设一个表包含两个系统用户之间的消息。我们可能有“sender_id”和“receiver_id”列，我们可能希望单独查询这些列。
如果我们在这两列上都有单独的索引，我们可以在必要时单独查询它们。结果很快。
但是如果我们的表有 100M 行大，并且我们考虑分区怎么办。我的理解是多列分区侧重于列定义中的第一列，然后是第二列。这是一个示例表结构：
CREATE TABLE messages (
message_id INT,
sender_id INT,
receiver_id INT
)
PARTITION BY RANGE COLUMNS(sender_id,receiver_id) (
PARTITION p0 VALUES LESS THAN (10,10),
PARTITION p1 VALUES LESS THAN (20,20),
PARTITION p3 VALUES LESS THAN (MAXVALUE,MAXVALUE)
如果我们查询“WHERE receiver_id=5”，分区修剪不会启动，对吧？它将需要搜索所有分区。但是如果我们要搜索“WHERE sender_id=5”，那么我们会立即知道结果在 p0 中。
因此，对于两个列可能各自重要的表，分区可能不是最好的解决方案，因为现在我们失去了在 columns 参数中为辅助列（receiver_id，在这种情况下）的全表索引的好处。那正确吗？
对于“并发插入”，MySQL参考手册有如下解释：
MyISAM 存储引擎支持并发插入，以减少给定表的读写器之间的争用：如果 MyISAM 表在数据文件中没有空洞（中间删除的行），则可以执行 INSERT 语句将行添加到末尾在 SELECT 语句从表中读取行的同时对表进行操作。
http://dev.mysql.com/doc/refman/5.5/en/concurrent-inserts.html
假设我们的数据库“并发插入”参数设置为“自动”(1)。
我们有一个有间隙的 MyISAM 表。当我们插入新行并填补这些空白时，表是否“立即”准备好接受未来插入查询的“并发插入”？
或者我们是否需要在表格知道没有间隙之前运行“OPTIMIZE”？
我们在 Centos 机器上有一个 MySQL 5.0 服务器。32GB内存。我们只有一个硬盘，374GB容量，50GB可用。我们所有的表都是 MyISAM。
当我们在硬盘中复制一个大文件（2GB-3GB）时，MySQL 会暂时变慢。文件复制不到一分钟。但是暂时的减速持续大约一个小时（甚至可能正好是一个小时）。
一小时过去后，突然间一切又恢复了正常。
感觉好像大文件复制推动 MySQL 开始使用硬盘驱动器作为内存，也许“sar -b”输出可以证明这一点。但是为什么mysql会开始使用硬盘驱动器，复制的文件大约占总内存的10%。
有什么想法可以防止这种情况发生吗？
这是 sar 输出，文件复制是在上午 11:00 左右完成的：
10:20:01 AM CPU %user %nice %system %iowait %steal %idle
10:30:01 AM all 5.52 0.00 4.40 5.35 0.00 84.72
10:40:01 AM all 5.38 0.00 4.34 5.34 0.00 84.93
10:50:01 AM all 6.44 0.00 4.86 7.00 0.00 81.70
11:00:01 AM all 6.06 0.00 4.33 6.48 0.00 83.12
11:10:02 AM all 6.18 0.00 6.11 9.60 0.00 78.11
11:20:01 AM all 1.92 0.00 1.95 8.58 0.00 87.55
11:30:01 AM all 2.23 0.00 2.59 8.53 0.00 86.64
11:40:01 AM all 3.63 0.00 3.57 8.95 0.00 83.85
这是 sar -r 的输出：
10:20:01 AM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
10:30:01 AM 823860 32125192 97.50 345996 24971808 34995984 232 0.00 0
10:40:01 AM 895852 32053200 97.28 360620 24877364 34995984 232 0.00 0
10:50:01 AM 295556 32653496 99.10 372440 25451620 34995984 232 0.00 0
11:00:01 AM 809260 32139792 97.54 395116 24869132 34995984 232 0.00 0
11:10:02 AM 430732 32518320 98.69 659220 23661112 34995984 232 0.00 0
11:20:01 AM 153580 32795472 99.53 687740 24438764 34995984 232 0.00 0
11:30:01 AM 251816 32697236 99.24 778396 24284876 34995984 232 0.00 0
11:40:01 AM 297912 32651140 99.10 782468 24354304 34995984 232 0.00 0
查看 sar -P ALL，CPU 1 有 %70+ iowait：
10:40:01 AM CPU %user %nice %system %iowait %steal %idle
10:50:01 AM all 6.44 0.00 4.86 7.00 0.00 81.70
10:50:01 AM 0 5.87 0.00 4.70 1.77 0.00 87.66
10:50:01 AM 1 12.14 0.00 5.80 44.59 0.00 37.48
10:50:01 AM 2 2.68 0.00 2.30 0.43 0.00 94.58
10:50:01 AM 3 5.90 0.00 4.07 11.72 0.00 78.31
10:50:01 AM 4 2.68 0.00 2.53 0.59 0.00 94.20
10:50:01 AM 5 6.45 0.00 4.88 9.13 0.00 79.54
10:50:01 AM 6 2.84 0.00 2.43 0.52 0.00 94.22
10:50:01 AM 7 5.04 0.00 4.31 3.04 0.00 87.61
10:50:01 AM 8 6.37 0.00 4.85 0.73 0.00 88.04
10:50:01 AM 9 8.88 0.00 6.45 17.30 0.00 67.37
10:50:01 AM 10 5.17 0.00 3.79 1.34 0.00 89.69
10:50:01 AM 11 10.85 0.00 8.95 8.72 0.00 71.48
10:50:01 AM 12 4.12 0.00 3.41 0.93 0.00 91.53
10:50:01 AM 13 10.27 0.00 7.59 7.06 0.00 75.08
10:50:01 AM 14 6.81 0.00 5.69 3.01 0.00 84.48
10:50:01 AM 15 6.94 0.00 6.00 1.15 0.00 85.91
11:00:01 AM all 6.06 0.00 4.33 6.48 0.00 83.12
11:00:01 AM 0 5.86 0.00 6.11 5.44 0.00 82.59
11:00:01 AM 1 11.14 0.00 4.55 45.71 0.00 38.60
11:00:01 AM 2 3.33 0.00 3.24 1.18 0.00 92.25
11:00:01 AM 3 4.33 0.00 3.04 7.62 0.00 85.01
11:00:01 AM 4 2.28 0.00 1.83 1.87 0.00 94.02
11:00:01 AM 5 4.61 0.00 4.51 3.97 0.00 86.91
11:00:01 AM 6 2.59 0.00 2.42 1.80 0.00 93.19
11:00:01 AM 7 3.90 0.00 3.23 2.55 0.00 90.33
11:00:01 AM 8 4.86 0.00 3.94 1.21 0.00 89.99
11:00:01 AM 9 7.06 0.00 5.12 12.43 0.00 75.39
11:00:01 AM 10 4.87 0.00 4.76 1.09 0.00 89.28
11:00:01 AM 11 6.42 0.00 5.20 5.67 0.00 82.71
11:00:01 AM 12 6.28 0.00 5.61 4.63 0.00 83.48
11:00:01 AM 13 14.10 0.00 7.61 4.17 0.00 74.12
11:00:01 AM 14 4.76 0.00 3.54 3.67 0.00 88.04
11:00:01 AM 15 10.64 0.00 4.61 0.74 0.00 84.01
11:00:01 AM CPU %user %nice %system %iowait %steal %idle
11:10:02 AM all 6.18 0.00 6.11 9.60 0.00 78.11
11:10:02 AM 0 5.79 0.00 4.76 1.17 0.00 88.28
11:10:02 AM 1 5.87 0.00 16.54 72.31 0.00 5.29
11:10:02 AM 2 3.24 0.00 3.04 4.31 0.00 89.42
11:10:02 AM 3 5.66 0.00 5.32 9.17 0.00 79.85
11:10:02 AM 4 3.81 0.00 3.40 1.59 0.00 91.20
11:10:02 AM 5 6.06 0.00 5.02 9.16 0.00 79.77
11:10:02 AM 6 4.10 0.00 3.94 0.71 0.00 91.25
11:10:02 AM 7 4.64 0.00 4.29 6.18 0.00 84.88
11:10:02 AM 8 6.19 0.00 5.12 0.50 0.00 88.20
11:10:02 AM 9 8.72 0.00 8.12 26.72 0.00 56.44
11:10:02 AM 10 6.37 0.00 4.78 1.01 0.00 87.83
11:10:02 AM 11 8.59 0.00 7.01 8.53 0.00 75.86
11:10:02 AM 12 5.43 0.00 5.09 0.72 0.00 88.76
11:10:02 AM 13 11.04 0.00 9.00 6.99 0.00 72.97
11:10:02 AM 14 5.60 0.00 5.33 1.12 0.00 87.95
11:10:02 AM 15 7.73 0.00 7.05 3.40 0.00 81.82
11:20:01 AM all 1.92 0.00 1.95 8.58 0.00 87.55
11:20:01 AM 0 1.85 0.00 1.79 11.58 0.00 84.78
11:20:01 AM 1 4.02 0.00 7.08 77.21 0.00 11.69
11:20:01 AM 2 1.32 0.00 1.14 1.08 0.00 96.46
11:20:01 AM 3 1.35 0.00 1.25 3.75 0.00 93.64
11:20:01 AM 4 1.29 0.00 1.11 1.08 0.00 96.53
11:20:01 AM 5 1.49 0.00 1.37 2.70 0.00 94.44
11:20:01 AM 6 1.59 0.00 1.27 0.92 0.00 96.21
11:20:01 AM 7 1.62 0.00 1.50 3.74 0.00 93.14
11:20:01 AM 8 1.84 0.00 1.68 3.32 0.00 93.15
11:20:01 AM 9 2.09 0.00 2.24 19.19 0.00 76.49
11:20:01 AM 10 2.15 0.00 1.42 1.02 0.00 95.41
11:20:01 AM 11 1.95 0.00 1.95 3.06 0.00 93.04
11:20:01 AM 12 1.90 0.00 1.68 1.10 0.00 95.32
11:20:01 AM 13 2.40 0.00 2.09 2.94 0.00 92.57
11:20:01 AM 14 1.90 0.00 1.87 1.14 0.00 95.09
11:20:01 AM 15 1.89 0.00 1.83 3.37 0.00 92.91
特区-W：
10:20:01 AM pswpin/s pswpout/s
10:30:01 AM 0.00 0.00
10:40:01 AM 0.00 0.00
10:50:01 AM 0.00 0.00
11:00:01 AM 0.00 0.00
11:10:02 AM 0.00 0.00
11:20:01 AM 0.00 0.00
11:30:01 AM 0.00 0.00
11:40:01 AM 0.00 0.00
sar -b，请注意上午 11 点之后的跳转。
10:20:01 AM tps rtps wtps bread/s bwrtn/s
10:30:01 AM 1941.72 296.49 1645.23 2619.86 26872.80
10:40:01 AM 2018.03 341.37 1676.66 3123.88 25695.44
10:50:01 AM 2581.44 460.03 2121.41 6384.41 35324.48
11:00:01 AM 3031.42 508.31 2523.11 4936.72 44437.03
11:10:02 AM 7222.13 1083.55 6138.58 61930.06 122374.97
11:20:01 AM 4832.72 1960.20 2872.53 55023.49 55869.57
11:30:01 AM 2174.64 1619.38 555.26 14751.91 9753.42
11:40:01 AM 2361.23 1682.74 678.49 15293.00 11799.85
11:50:01 AM 2210.12 1433.24 776.88 12757.86 13321.64
12:00:01 PM 3439.84 932.84 2507.01 22081.47 44653.18
我一直在研究 SQL_BUFFER_RESULT 的用法。大多数情况下，它被称为减少表锁定问题的辅助工具。
这似乎是一个不错的选择。
但是，我似乎找不到任何缺点。它是大多数时候应该使用的选项吗？
我的理解是 mysqlhotcopy 的工作原理与 rsync 非常相似。
在我们的一台服务器中，使用 rsync 备份数据库文件大约需要 15 分钟才能处理 50GB 数据。
使用 mysqlhotcopy 备份相同的数据大约需要 30 分钟。
为什么 mysqlhotcopy 明显变慢了？
我们最近将我们的一张表切换到了 innodb，现在我们正在经历非常缓慢的 UPDATE 执行时间。过去需要 0.010-0.030 秒的更新现在可能需要超过 70 秒。一些查询被丢弃是因为它们无法在默认的 50 秒限制内获得锁（我意识到我们可以提高这个限制）。
有问题的表只有一个索引，主键本身是一个 mediumint 值。该表有大约 100 万行。此上下文中的所有 UPDATE 都涉及单行。通常，该行中的 4-5 列在每个查询中都会受到影响。
当前的 my.cnf 粘贴在下面。您是否看到任何可能特别导致 innodb 更新性能不佳的内容？
[mysqld]
set-variable=local-infile=0
datadir=/db/mysql/data
socket=/var/lib/mysql/mysql.sock
#log = /var/log/mysqld.log
log-error = /var/log/mysqld.error.log
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
skip-locking
key_buffer = 1G
query_cache_size = 256M
thread_cache_size = 128
table_cache = 2048
max_connections = 400
query_cache_limit = 1024M
log_slow_queries = /var/log/mysql-slow.log
long_query_time = 1
skip-bdb
skip-locking
skip-name-resolve
innodb_buffer_pool_size=1G
innodb_additional_mem_pool_size=20M
innodb_flush_log_at_trx_commit=2
#innodb_log_file_size=250M
innodb_log_buffer_size=8M
innodb_lock_wait_timeout=50
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
更新：
innodb_log_file_size: 5242880
have_innodb: YES
"WHERE" 子句总是只查找一列，这是主键。
更新 - 2012 年 7 月 26 日：
我们将数据库升级到 mysql 5.5。现在 innodb 更新非常快，在我们的特定情况下不到 0.010 秒。而且，方差非常低。我对此的看法是：在 mysql 5.0 上应谨慎使用 innodb。
我试图了解如何最好地解释我们的 MySQL 慢查询日志中显示的查询的锁定时间。
例如，如果一个 UPDATE 查询有 10 秒的锁定时间。我认为这是更新查询获取锁后的总时间。即使它正在等待先前的选择查询完成但不执行 UPDATE 操作本身，时钟也应该在滴答作响，因为它锁定了在 UPDATE 查询之后排队的所有 SELECT 查询。
以及 SELECT 查询锁怎么样。为什么某些选择查询有锁定时间？是不是因为有一个 UPDATE 查询跟进，因此他们将一个表锁定在一起。