MariaDB 在取消索引创建后等待
MariaDB waits after canceling index creation
我们有一个 MariaDB 数据库 运行 WordPress 4.8，在 wp_options table 中发现了很多 transient 命名记录。 table 已使用插件清理并从约 80 万条记录减少到约 2 万条记录。关于 table:
的查询条目仍然很慢
# User@Host: wmnfdb[wmnfdb] @ localhost []
# Thread_id: 950 Schema: wmnf_www QC_hit: No
# Query_time: 34.284704 Lock_time: 0.000068 Rows_sent: 1010 Rows_examined: 13711
SET timestamp=1510330639;
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';
找到另一个 post 来创建索引并做了:
ALTER TABLE wp_options ADD INDEX (`autoload`);
这花费的时间太长，导致网站脱机。我在进程列表中发现了很多'Waiting for table metadata lock'。取消 ALTER TABLE 后，再次获得所有 运行 仍然具有高负载和慢查询日志中的条目。我还尝试使用脱机的 Web 服务器和干净的进程列表创建索引。今晚再创作要这么久吗？
如果您要删除 table 的 大部分 ，最好创建一个新的 table，复制所需的行，然后重命名。不幸的是，这些步骤中的任何 added/modified 行都不会反映在复制的 table 中。 （加号：您可能已经有了新索引。）
在this中，我给出了多种大删除的方法。
什么是可能挂起你的系统：
一个大的 DELETE 会隐藏所有旧值以防回滚——这会杀死调用的 DELETE！让它完成可能会更快。
ALTER TABLE .. ADD INDEX -- 如果您使用的是 MySQL 5.5 或更早版本，则必须将整个 table 复制过来。即使您使用的是更新版本（可以 ALGORITHM=INPLACE），仍然存在元数据锁定。 wp_options 被触摸的频率是多少？ （听起来太多次了。）
底线：如果您从尝试中恢复过来，但删除仍未完成，请在我的 link 中选择最佳方法。在那之后，仅向 20K 行添加索引应该需要一些时间，但不会是致命的长时间。并考虑升级到 5.6 或更新版本。
如需进一步讨论，请提供SHOW CREATE TABLE wp_options。
但是等等！如果 autoload 是一个简单的 yes/no 'flag'，则可能不会使用该索引。也就是说，加索引可能是一种浪费！ （对于低基数，执行 table 扫描比在索引 BTree 和数据 BTree 之间来回跳转 更快 。）请提供 link 那个 post;我想吐口水给他们。
我们有一个 MariaDB 数据库 运行 WordPress 4.8，在 wp_options table 中发现了很多 transient 命名记录。 table 已使用插件清理并从约 80 万条记录减少到约 2 万条记录。关于 table:
的查询条目仍然很慢# User@Host: wmnfdb[wmnfdb] @ localhost []
# Thread_id: 950 Schema: wmnf_www QC_hit: No
# Query_time: 34.284704 Lock_time: 0.000068 Rows_sent: 1010 Rows_examined: 13711
SET timestamp=1510330639;
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';
找到另一个 post 来创建索引并做了:
ALTER TABLE wp_options ADD INDEX (`autoload`);
这花费的时间太长，导致网站脱机。我在进程列表中发现了很多'Waiting for table metadata lock'。取消 ALTER TABLE 后，再次获得所有 运行 仍然具有高负载和慢查询日志中的条目。我还尝试使用脱机的 Web 服务器和干净的进程列表创建索引。今晚再创作要这么久吗？
如果您要删除 table 的 大部分 ，最好创建一个新的 table，复制所需的行，然后重命名。不幸的是，这些步骤中的任何 added/modified 行都不会反映在复制的 table 中。 （加号：您可能已经有了新索引。）
在this中，我给出了多种大删除的方法。
什么是可能挂起你的系统：
一个大的 DELETE 会隐藏所有旧值以防回滚——这会杀死调用的 DELETE！让它完成可能会更快。
ALTER TABLE .. ADD INDEX -- 如果您使用的是 MySQL 5.5 或更早版本，则必须将整个 table 复制过来。即使您使用的是更新版本（可以 ALGORITHM=INPLACE），仍然存在元数据锁定。 wp_options 被触摸的频率是多少？ （听起来太多次了。）
底线：如果您从尝试中恢复过来，但删除仍未完成，请在我的 link 中选择最佳方法。在那之后，仅向 20K 行添加索引应该需要一些时间，但不会是致命的长时间。并考虑升级到 5.6 或更新版本。
如需进一步讨论，请提供SHOW CREATE TABLE wp_options。
但是等等！如果 autoload 是一个简单的 yes/no 'flag'，则可能不会使用该索引。也就是说，加索引可能是一种浪费！ （对于低基数，执行 table 扫描比在索引 BTree 和数据 BTree 之间来回跳转 更快 。）请提供 link 那个 post;我想吐口水给他们。