【问题标题】:Any way to reduce 'FTS_*_*_INDEX_1.ibd' file sizes in MySQL database folder?有什么方法可以减少 MySQL 数据库文件夹中的“FTS_*_*_INDEX_1.ibd”文件大小?
【发布时间】:2017-01-30 17:31:29
【问题描述】:

我有一个包含大约 240Gb 数据和索引的大型数据库(从 phpMyAdmin 读取 - 我的表在 innodb 中)。然而,服务器上的数据库文件夹大小接近 400Gb,而我的 ibdata1 文件大小约为 6Gb,导致我的 SSD 空间不足。

我对此进行了调查,似乎有很多文件,如FTS_0000000000000f86_00000000000019db_INDEX_1.ibd,大小为数十 GB。他们似乎(根据他们的文件名)我的关联表的全文索引,每个有 6 个(FTS_*_INDEX_1.ibdFTS_*_INDEX_6.ibd)。

我进行了搜索,发现了这些帖子:

Howto: Clean a mysql InnoDB storage engine?

Database space doesn't match ibdata1 size

我已经在 cmets 中就这两个问题/答案提出了我的问题,但尚未得到答复。所以我决定直接在这里问我的问题。

如果我在启用innodb_file_per_table 的情况下执行“InnoDB 清理”(如the first link above 中所建议的那样),我的数据库文件夹中是否还会有很多以FTS_\*_INDEX_1.ibd 开头的大文件?这种方法是否仅有助于减少 ibdata1 文件大小?这些大桌子上的常规OPTIMIZE TABLE(如建议的那样)会帮助我解决我的问题吗?

谢谢!

更新:

这是按文件大小反向排序的大于 1Gb 的文件列表(文件名已更改):

-rw-rw----. 1 mysql mysql  1300234240 Jan 30 18:28 FTS_0000000000000fc2_DELETED.ibd
-rw-rw----. 1 mysql mysql  1375731712 Jan  7 21:41 FTS_0000000000000f86_00000000000019db_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  1585446912 Jan 30 23:17 FTS_0000000000001000_0000000000001a68_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  1593835520 Jan  7 21:41 FTS_0000000000000f86_00000000000019bf_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  1673527296 Jan 29 23:41 FTS_0000000000001000_DELETED.ibd
-rw-rw----. 1 mysql mysql  1824522240 Jan  7 21:41 FTS_0000000000000f86_00000000000019cd_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  2172649472 Jan 30 01:16 FTS_0000000000001073_0000000000001b3c_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  2281701376 Jan  7 21:41 FTS_0000000000000f86_00000000000019b1_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  2357198848 Jan 31 02:53 FTS_0000000000000fc2_0000000000001a0f_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  2495610880 Jan 28 13:59 FTS_0000000000000fc2_0000000000001a2b_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  2906652672 Jan 30 23:18 FTS_0000000000001000_0000000000001a76_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  3984588800 Jan 30 23:18 FTS_0000000000001000_0000000000001a6f_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  4135583744 Jan 30 08:03 FTS_0000000000000fc2_00000000000019fa_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  5716836352 Jan 28 13:59 FTS_0000000000000fc2_0000000000001a01_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  6400507904 Jan 31 05:39 my_k.ibd
-rw-rw----. 1 mysql mysql  7449083904 Jan  7 21:41 FTS_0000000000000f86_00000000000019d4_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  8115978240 Jan  7 21:41 FTS_0000000000000f86_00000000000019c6_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  8308916224 Jan 30 08:03 FTS_0000000000000fc2_0000000000001a16_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  8434745344 Jan  7 21:41 FTS_0000000000000f86_00000000000019b8_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  9244246016 Jan  7 21:41 FTS_0000000000000f86_00000000000019aa_INDEX_1.ibd
-rw-rw----. 1 mysql mysql  9714008064 Jan 30 01:16 my_a.ibd
-rw-rw----. 1 mysql mysql 12738101248 Jan 31 05:43 my_s.ibd
-rw-rw----. 1 mysql mysql 14038335488 Jan 31 02:53 FTS_0000000000000fc2_0000000000001a24_INDEX_1.ibd
-rw-rw----. 1 mysql mysql 19906166784 Jan 30 08:03 FTS_0000000000000fc2_0000000000001a1d_INDEX_1.ibd
-rw-rw----. 1 mysql mysql 21185429504 Jan 31 05:43 my_p_s.ibd
-rw-rw----. 1 mysql mysql 29242687488 Jan 31 02:54 FTS_0000000000000fc2_0000000000001a32_INDEX_1.ibd
-rw-rw----. 1 mysql mysql 30131879936 Jan  5 16:35 my_p.ibd
-rw-rw----. 1 mysql mysql 47085256704 Jan 31 05:43 my_a_c.ibd
-rw-rw----. 1 mysql mysql 76499910656 Jan 31 05:43 my_p_c.ibd
-rw-rw----. 1 mysql mysql 76743180288 Jan 30 00:09 my_r.ibd

【问题讨论】:

  • 索引为FULLTEXT 的表有多大(GB)?
  • 只显示目录中所有(相关)文件的大小;我在挥手中迷路了。
  • 我实际上有 8 个大小超过 1 GB 的表和大约 20 个大小超过 1 GB 的 FTS_*_INDEX_1.idb 文件。你想让我怎么给你看文件和它们的大小?喜欢主要问题中的列表?
  • 在 Unix 中,ls -l 在目录中。在 Windows 中dir。要么显示名称和大小。
  • @RickJames,我已在问题正文中添加了列表。

标签: mysql database full-text-search innodb


【解决方案1】:

正如您所怀疑的,FTS_*.ibd 文件是 InnoDB FULLTEXT 索引文件。缩小这些文件的最佳方法通常是删除并重新创建您的 FULLTEXT 索引。执行OPTIMIZE TABLE 可能有帮助,也可能没有帮助,具体取决于您是否启用了innodb_optimize_fulltext_only,但回收空间最安全的选择是删除/添加。

在仅插入工作负载上,删除/添加通常会使文件更小,如果这些表得到大量更新和/或删除,那么删除/添加所节省的大小应该会更大。大型 FTS_*_DELETED.ibd 文件的存在意味着您已从这些表中删除了一些数据,因此删除/添加索引将为您节省一些磁盘空间。

您可以使用SHOW CREATE TABLE 找出现有 FULLTEXT 索引的名称和列,以便正确地重新创建它们。

例如:

mysql > show create table your_table\G
*************************** 1. row ***************************
       Table: your_table
Create Table: CREATE TABLE `your_table` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `col1` varchar(255) DEFAULT NULL,
  `col2` varchar(255) DEFAULT NULL,
  ...
  PRIMARY KEY (`id`),
  FULLTEXT KEY `fti_idx` (`col1`,`col2`)
) ENGINE=InnoDB;
1 row in set (0.00 sec)

然后您可以在单个 ALTER TABLE 语句中删除和添加索引:

alter table your_table
  drop index fti_idx,
  add fulltext index fti_idx (col1,col2);

【讨论】:

  • 我遇到的问题是我的 400Gb SSD 快满了,我无法进行很多操作。我想我会转储数据库并再次导入它。这应该重新创建所有索引,包括 FT 索引,并希望腾出一些空间。如果我有任何更新,我会回到这里。
  • 与重建整个表不同,删除 FULLTEXT 索引然后再次添加它们应该不需要超出已使用的任何额外磁盘空间。如果您进行转储并重新导入它,这应该会通过回收因更新和删除而浪费的空间来缩小文件,但如果您删除/添加全文索引,它不会获得您获得的全部空间节省。跨度>
  • 在整个数据库的转储导入过程失败后,我刚刚开始重新定义我的 FT 索引。我很容易删除了旧索引,但是在重新定义一些索引(那些在带有一段文本的列上的索引)时,mysql 连接会因“mysql 消失问题”而丢失。我正在使用 phpMyAdmin
  • 我可以澄清一下,在我的情况下,一个简单的 OPTIMIZE 将千兆字节大小的文件减少到文件或几兆字节。这绝对应该是首先尝试的。
【解决方案2】:

*.ibd 文件都是 InnoDB 表空间文件。它们包含以 file-per-table 方式存储的 InnoDB 表的数据和/或索引。通常,文件名与它们存储的表相匹配,您肯定已经知道了。

FTS_*.ibd 文件是 InnoDB 实现全文索引的索引。这是 MySQL 5.6 中引入的一个新特性,关于存储特性的文档知识并不多。显然,出于某种原因,它们非常笨重。我不知道OPTIMIZE TABLE 是否对全文索引有任何影响。

摆脱这些大文件的一种方法当然是删除为 InnoDB 表定义的任何全文索引。

其他一些全文索引产品,如 ElasticSearch 或 Apache Solr 或 Sphinx Search 可能会更紧凑地存储它们的索引。我在这里对全文索引解决方案进行了比较:

Full Text Search Throwdown

InnoDB 的全文索引是我测试过的最慢的解决方案,除了LIKE '%pattern%' 的表扫描。

【讨论】:

  • 谢谢比尔,我遇到的问题是我的 400Gb SSD 快满了,我无法进行很多操作。我想我会转储数据库并再次导入它。这应该重新创建所有索引,包括 FT 索引,并希望腾出一些空间。如果我有任何更新,我会回到这里。关于你的幻灯片,我以前看过,我想我应该坚持 69 的幻灯片 64! :) 我不知道如何迁移到像 Sphinx Search 这样的东西以及它会带来什么复杂性。
  • Bill,转储和重新生成整个数据库的过程不成功。花了 48 多小时还在处理中,所以我取消了它。我刚开始重新定义我的 FT 索引。我很容易删除了旧索引,但是在重新定义一些索引(那些在带有一段文本的列上)时,mysql 连接会因“mysql 消失问题”而丢失。我正在使用 phpMyAdmin
  • 如果您空间有限,这是我建议切换到 MyISAM 的少数几次之一,至少对于需要全文索引的表来说是这样。 MyISAM 通常比 InnoDB 更紧凑地存储数据。我管理一个我们使用 MyISAM 的数据库服务器,因为如果我们使用 InnoDB,那么该服务器上的数据确实不适合。
  • FWIW,我从不使用 phpMyAdmin。我在命令行工作。并确保在运行 tmuxscreen 的 shell 中工作,因此如果您的连接断开,您在该窗口中所做的任何事情都会继续,您可以重新连接到该会话。
猜你喜欢
  • 1970-01-01
  • 2010-09-17
  • 1970-01-01
  • 1970-01-01
  • 2018-11-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多