在MySQL中，移动分区目录后，数据仍然可以访问

Question

我的分区方案看起来像：

ALTER TABLE my_table
PARTITION BY RANGE (integer_field) (
PARTITION p0 VALUES LESS THAN (100) DATA DIRECTORY = '/my_location/partitions/p0'  ,
PARTITION p1 VALUES LESS THAN (200) DATA DIRECTORY = '/my_location/partitions/p1' ,
PARTITION p_other VALUES LESS THAN (MAXVALUE) DATA DIRECTORY = '/my_location/partitions/p_other'
);

正如预期的那样，数据被正确地存储到分区和正确的目录中。

问题：

现在，当我从这个位置移除/移动目录时，就像mv /my_location/partitions/p0 /some_other_location/一样，目录会成功移动，但即使在重新启动外壳之后，数据仍然可以从MySQL外壳中查询。

我的解决方案：

为了使它按预期工作，在移动包括.ibd文件在内的目录后，我必须明确地删除分区：

ALTER TABLE my_table DROP PARTITION p0;

这根据需要从方案中删除了分区，还清除了数据，通过再次查询相同的数据进行验证。

假设/理解：

我认为MySQL正在缓存数据，不确定数据的确切位置和原因，这使得它即使在分区目录被移走后也可以查询。当我关闭并重新加载外壳时，缓存肯定不在连接级别。

问题：

我预计一旦目录p0被移走，数据就会消失。真的有必要在每次移动目录时运行drop partition语句吗？

限制：

可以肯定的是，只有当p0分区不再使用时，p0目录才会被移走。因此，将不再需要任何数据进入现有的p0分区

MySQL：8.0.19

Answer 1

Windows？

你重新启动了mysqld吗？

Linux上的CCD_ 7(及其近亲(实际上是一个"；重命名"；。而且，假设目标位于同一个文件系统上，则重命名甚至可能涉及不同的目录。

当程序(例如，mysqld(具有文件(例如，表分区(时；打开"；mysqld，它可以控制它——即使你跑到一个shell并rm文件！。

我怀疑当您重新启动mysqld(出于任何原因，包括重新启动(时；数据目录"；会变得一团糟。

除了文件系统的分区之外，当您"；档案"；隔板。阅读"；可运输的表空间">用于您正在使用的版本。这是一篇5.6的文章；5.7有一些改进。

我看不出使用文件系统分区有什么好处。用"；可运输的桌子空间"；，您可以断开MySQL分区与PARTITIONed表的连接。这将分区变成一个表。然后，该表可以被删除、重命名、复制等，而不会影响分区表。搜索"；可运输"；在里面http://mysql.rjweb.org/doc.php/partitionmaint；有一些链接。

Answer 2

正如@Rick James和@Solarflare所指出的，在ibd文件仍然处于MySQL的打开状态时，在文件中移动确实会有奇怪的行为，表空间会变得一团糟。根据他们的指导和MySQL文档，以下是对我成功起作用的最后一种方法(可能是正确的方法(：

1. 锁定表格

   FLUSH TABLES my_table FOR EXPORT;
   

   这样可以防止对所需表进行任何更新/写入操作，并使ibd文件可以安全复制。此外，这将创建一个.cfg文件。这些步骤在MySQL Docs 中有很好的解释

2. 一旦表是"；锁定"；，将.ibd文件复制到所需位置进行存档。PS：暂时不要移动/删除源文件。

   cp -r /my_location/partitions/p0  /some_other_location/
   

3. 解锁表以能够更改分区

   UNLOCK TABLES;
   

4. 安全放下所需的分区。这也会通知表空间。

   ALTER TABLE my_table DROP PARTITION p0;
   

   请注意，此语句将导致删除分区以及与该分区对应的数据。