我有一个繁忙的数据库，只有 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 …我已经看到一些专用的 MySQL 服务器，它们只使用一个内核。我比 MySQL 的 DBA 更擅长开发，所以需要一些帮助
服务器非常庞大，具有 OLAP/DataWarehouse (DW) 类型的负载：
注意：最大的 DB 是从 OLTP DR 服务器复制的 DB，DW 就是从这里加载的。它不是完整的 DW：仅持续 6 个月到 6 周，因此它比 OLTP DB 小。
ALTER TABLE...DROP KEY...ADD INDEXH2 是一个单线程数据库，在性能方面享有盛誉。其他数据库是多线程的。
我的问题是：多线程数据库什么时候变得比单线程数据库更有趣？有多少用户？多少个进程？什么是触发器？有人有经验可以分享吗？
概括
这是一个纯理论问题。假设我在多台服务器上部署了一个应用程序。
在前两个部分，我知道要寻找什么。但是数据库服务器呢？我应该寻找什么样的硬件？
PS：假设选择的数据库是 MySQL 或 PostgreSQL。
我想针对其他一些分支（例如 Percona 服务器、MariaDB 以及可能的其他分支）对 MySQL 服务器 rpm 进行性能测试（又名烘焙）。我希望通过提出这个问题，我可以更好地理解设置适当性能测试背后的方法。我计划使用 sysbench 来运行我的实际测试，但我对任何事情都持开放态度。
我目前正在研究一个 MySQL 数据库，我们看到查询缓存中有大量无效，主要是因为在许多表上执行了大量的 INSERT、DELETE 和 UPDATE 语句。
我要确定的是，允许将查询缓存用于针对这些表运行的 SELECT 语句是否有任何好处。由于它们很快就失效了，在我看来，最好的办法是在这些表的 SELECT 语句上使用 SQL_NO_CACHE。
频繁失效的开销值得吗？
编辑：应以下用户@RolandoMySQLDBA 的要求，这里是有关 MyISAM 和 INNODB 的信息。
数据库
我的ISAM
附加信息：
什么是 Percona？
它与 MySQL 有何不同？
我们什么时候应该考虑从库存 MySQL 切换（或升级）到 Percona？
为了在我们的情况下添加一些细节，我们几乎只使用具有广泛外键约束和一些存储过程的 InnoDB（我知道 Percona 已经做了很多优化）。
我们目前发现 MySQL 对我们的查询优化不佳，因此任何超过 3-4 个连接的查询我们都必须使用 STRAIGHT 连接显式构建以提高性能。
我的要求是：
目前，我们将高 CPU 超大实例的连接数最大化为 700。所有 8 个内核都已达到最大值。我们认为这是并发连接数，因为内存很好。写入本身非常简单（验证缓慢）。要扩展到 3000，我们需要转到多台服务器，当前选项：
要处理这个数量的连接，有几个问题：
如果我没有很好地描述我的问题，我深表歉意。请提问。
由于 RAM 的限制，是否可以让 InnoDB 使用与 MyISAM 相同的索引而不是聚集索引，同时获得其并发性能的好处？
在我的一个生产环境中，我们有两个实例在 RedHat 集群上运行，其中一个生产实例与该集群关联。
我们有 125G 主内存，24G InnoDB 缓冲池被 instance1 占用，12G 被 instance2 占用，这与 RedHat 集群无关。数据和事务日志都位于具有 ext3 文件系统的 LVM 磁盘分区上。
为了提高性能和更好的 I/O 吞吐量，我决定更改innodb_flush_method为O_DIRECT.
参考 MySQL 文档：
InnoDB 数据和日志文件位于 SAN 上，我们发现设置
innodb_flush_method为O_DIRECT会使简单SELECT语句的性能降低三倍。
提到高性能 MySQL Ver 2 和 3，它表示 InnoDB 开发人员发现使用innodb_flush_method=O_DSYNC. O_SYNCandO_DSYNC类似于fsync()and fdatasync()：O_SYNC同步数据和元数据，而O_DSYNC只同步数据。
如果这一切看起来像是没有建议的很多解释，那么建议如下：
如果您使用类 Unix 操作系统并且您的 RAID 控制器具有电池供电的写入缓存，我们建议您使用
O_DIRECT. 如果没有，O_DIRECT根据您的应用程序，默认值或可能是最佳选择。
通过谷歌搜索，我得到了这个基准报告：on O_DSYNCvsO_DIRECT
基准报告： ==================== 1B …