我目前有一个应用程序使用 130 个 MySQL 表，所有表都带有 MyISAM 存储引擎。每个表每秒都有多个查询，包括选择/插入/更新/删除查询，因此数据和索引不断变化。
我面临的问题是硬盘无法应对，I/O 访问的等待时间长达 6 秒以上，而 MySQL 完成了如此多的读/写操作。
我正在考虑更改为仅 1 个表并使其基于内存。不过，我从来没有将内存表用于有这么多查询的东西，所以我想知道是否有人可以就这是否是正确的做法给我任何反馈？
问问题
1084 次
4 回答
2
一种可能性是可能存在导致性能问题的其他问题 - 6 秒对于 CRUD 操作来说似乎太长了，即使在复杂的数据库上也是如此。请记住，（过去）ArsDigita 可以在具有相当适中的磁盘配置的双向 Sun Ultra 2 (IIRC) 上每秒处理 30 次点击。具有合理磁盘布局和适当调整的现代中低端服务器应该能够应对相当大的工作量。
您是否缺少索引？- 检查慢速查询的查询计划以查找不应该进行的表扫描。
服务器上的磁盘布局是什么？- 您是否需要升级硬件或修复一些磁盘配置问题（例如磁盘不足、日志与数据在同一卷上）。
正如另一张海报所暗示的，您可能希望在大量写入的表上使用 InnoDB。
检查数据库服务器上的内存使用设置。您可能想要配置更多缓存。
编辑：数据库日志应该存在于它们自己的安静磁盘上。他们使用带有许多小顺序写入的顺序访问模式。当他们与数据文件等随机访问工作负载共享磁盘时，随机磁盘访问会在日志上造成很大的系统性能瓶颈。请注意，这是需要完成的写入流量（即写入物理磁盘），因此缓存对此无济于事。
于 2009-11-05T12:25:27.623 回答
1
我现在已更改为 MEMORY 表，一切都好得多。事实上，我现在在服务器上有额外的备用资源，可以进一步扩展操作。
于 2009-11-11T12:41:24.237 回答
0
您不使用innodb是否有特定原因？由于缓存和不同的并发模型，它可能会产生更好的性能。它可能需要更多的调整，但可能会产生更好的结果。
于 2009-11-05T11:57:26.687 回答
0
我认为您的数据库结构非常错误，需要优化，与存储无关
于 2009-11-05T12:34:36.640 回答