我们有一个带有 AWS RDS 的 MySQL 服务器(版本 5.6.34)。我们专门使用 MyISAM 表。我尝试更改 key_block_size 以增加 IO 吞吐量。然而，出现了两个意想不到的结果。
1> 如果key_block_size设置在索引级别(例如8192)，那么当执行完成时，表将转入InnoDB，这不是我想要的。要将表更改回 MyISAM，我必须删除索引。
2> 如果key_block_size是在表级别设置的(例如16384)，那么建立索引需要很长的时间。所花费的时间至少比未设置 key_block_size 的表长很多倍。
对于可能发生的事情以及原因有什么想法吗？我应该玩值(value)，即。 key_block_size，对于 MyISAM 表？
非常感谢您的见解。
最佳答案
默认 key block 大小为 1K。操作系统喜欢 4K。如果您的索引访问是随机，则越小越好。如果您在索引中进行范围扫描，则越大越好。
将key_buffer_size设置得太大会影响数据的缓存。让它太小会导致索引的 I/O 增加。您是否不小心打破了平衡？
我从未听说过 ENGINE 会自动更改。请提供更多详细信息。您在评论中的测试用例返回了 Percona 5.6.22-71.0-log 的 MyISAM 表，并且它确实保留了 KEY_BLOCK_SIZE=8192。 (我没有尝试 AWS。)哦，我想我找到了它:SHOW VARIABLES LIKE '%engine%'; 嗯... Percona 5.7.10-1 的更新日志说:“正在运行 ALTER TABLE 未指定存储引擎(不带 ENGINE= 子句)或在启用 enforce_storage_engine 时使用 OPTIMIZE TABLE 可能会导致未请求和意外的存储引擎更改。如果对系统表执行此操作，它将绕过常规系统表存储引擎兼容性检查，从而导致崩溃或以其他方式破坏服务器操作。错误已修复#1488055。”
有一种棘手的方法可以让 MyISAM 通过“排序”而不是通过“key_buffer”来重建索引。 (SHOW PROCESSLIST 显示它正在做什么。)(它说它正在“修复”。)“排序”通常要快得多，并且避免了 key_buffer。
检查delay_key_write的值。
在 MyISAM 中，PRIMARY KEY 算作另一个索引。在 InnoDB 中，它与数据聚集在一起，因此不会显示在 Index_length 中。
有很多优化和I/O技巧。 但是它们更多地依赖于查询而不是调优。请提供查询、EXPLAIN SELECT ...、RAM 大小和SHOW CREATE TABLE。另外，让我们看看SHOW VARIABLES LIKE '%buffer%';。
如果您想获得更多批评，请提供 SHOW VARIABLES; 和 SHOW GLOBAL STATUS;。
分析——也许“汇总表”是正确的选择？有时这会带来 10 倍的性能提升。
分析——当您可以通过集群 PK 进行扫描时，使用 InnoDB 可以获得比使用 MyISAM 更好的性能，后者必须在单独的索引和数据之间来回切换。和/或必须进行单独的排序。
Oracle 不断改进 InnoDB，以至于他们宣称它在几乎所有情况下都比 MyISAM 更好。其余不足:磁盘空间；没有 where 的 count(*)； 2部分PK。 (如果没有看到您的分析，我无法判断 InnoDB 是否真的会更快。他们也不能。)
关于mysql - 设置了 key_block_size 的 MyISAM 表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46596742/