我有一个繁忙的数据库，只有 InnoDB 表，大小约为 5GB。数据库在使用 SSD 磁盘的 Debian 服务器上运行，我设置了最大连接数 = 800，这有时会饱和并使服务器停止运行。平均每秒查询约 2.5K。所以我需要优化内存使用，为最大可能的连接腾出空间。
我已经看到建议 innodb_buffer_pool_size 应该高达总内存的 %80。另一方面，我从调整引物脚本中收到此警告：
Max Memory Ever Allocated : 91.97 G
Configured Max Per-thread Buffers : 72.02 G
Configured Max Global Buffers : 19.86 G
Configured Max Memory Limit : 91.88 G
Physical Memory : 94.58 G
这是我当前的 innodb 变量：
| innodb_adaptive_flushing | ON |
| innodb_adaptive_hash_index | ON |
| innodb_additional_mem_pool_size | 20971520 |
| innodb_autoextend_increment | 8 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_instances | 1 …我有一个带有 InnoDB 数据库的 symfony 应用程序，它有 57 个表，大约 2GB。数据库的大部分大小驻留在单个表中（~1.2GB）。我目前正在使用 mysqldump 每晚备份数据库。
由于我的 comcast 连接，通常如果我手动运行转储，我与服务器的连接将在转储完成之前超时，导致我不得不重新运行转储。[我目前运行一个每晚执行转储的 cron，这仅适用于我手动运行的转储。]
有没有办法加快连接超时问题的转储，同时也可以限制服务器被这个进程占用的时间？
顺便说一句，我目前正在努力减少整个数据库的大小来解决这个问题。
我已经看到一些专用的 MySQL 服务器，它们只使用一个内核。我比 MySQL 的 DBA 更擅长开发，所以需要一些帮助
服务器非常庞大，具有 OLAP/DataWarehouse (DW) 类型的负载：
注意：最大的 DB 是从 OLTP DR 服务器复制的 DB，DW 就是从这里加载的。它不是完整的 DW：仅持续 6 个月到 6 周，因此它比 OLTP DB 小。
ALTER TABLE...DROP KEY...ADD INDEX所以我对调整 InnoDB 还很陌生。我正在慢慢地将表（在必要时）从 MyIsam 更改为 InnoDB。我在 innodb 中有大约 100MB，所以我将innodb_buffer_pool_size变量增加到 128MB：
mysql> show variables like 'innodb_buffer%';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)
当我去更改innodb_log_file_size值时（例如mysql 的 innodb 配置页面上的my.cnf注释将日志文件大小更改为缓冲区大小的 25%。所以现在我的 my.cnf 看起来像这样：
# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M
当我重新启动服务器时，出现此错误：
110216 9:48:41 InnoDB：初始化缓冲池，大小 = 128.0M
110216 9:48:41 InnoDB：缓冲池初始化完成
InnoDB：错误：日志文件 ./ib_logfile0 的大小不同 0 5242880 字节
InnoDB：比指定的.cnf 文件 0 33554432 字节！
110216 9:48:41 [错误] …
我有这个巨大的 32 GB SQL 转储，我需要将其导入 MySQL。我以前不必导入如此庞大的 SQL 转储。我做了通常的：
mysql -uroot dbname < dbname.sql
时间太长了。有一个大约有 3 亿行的表，在大约 3 小时内达到了 150 万行。因此，整个过程似乎需要 600 小时（即 24 天）并且不切实际。所以我的问题是，有没有更快的方法来做到这一点？
innodb_flush_log_at_trx_commit = 2建议的设置似乎没有（明显可见/指数级）改进。我在 MySQL 数据库中有两个表 - parent, child. 我正在尝试根据父表向我的子表添加外键引用。有没有之间的任何显著差异ON UPDATE CASCADE和ON DELETE CASCADE
我的父表
CREATE TABLE parent (
id INT NOT NULL,
PRIMARY KEY (id)
) ENGINE=INNODB;
我的问题是：以下 sql 查询有什么区别。
ON DELETE CASCADE
CREATE TABLE child (
id INT,
parent_id INT,
INDEX par_ind (parent_id),
FOREIGN KEY (parent_id)
REFERENCES parent(id)
ON DELETE CASCADE
) ENGINE=INNODB;
ON UPDATE CASCADE
CREATE TABLE child (
id INT,
parent_id INT,
INDEX par_ind (parent_id),
FOREIGN KEY (parent_id)
REFERENCES parent(id)
ON UPDATE CASCADE
) …我有一些生产服务器，其ibdata文件的大小每天都在增加。
它已经消耗了 290GB 的空间。
服务器中的表多为InnoDB，读写请求量大。
日志文件大小也在增加。表中有大量数据。
我怎样才能控制两者的增长规模？
我没有使用innodb_file_per_table.
我有一个存储 MD5 哈希的索引列。因此，该列将始终存储 32 个字符的值。无论出于何种原因，它都是作为 varchar 而不是 char 创建的。迁移数据库以将其转换为字符是否值得？这是在带有 InnoDB 的 MySQL 5.0 中。
我转身innodb_flush_log_at_trx_commit = 2获得了非常快的写入速度。但是在生产网站中使用它安全吗？