【发布时间】:2020-01-22 14:52:27
【问题描述】:
MariaDB's documentation about partitioning 将其限制之一列为,
- 分区表不能包含外键,也不能被外键引用。
在 DBMS 的上下文中,具有此类限制的表有什么用?我认为我从未见过没有通过外键关联表的数据库设计,所以我想知道我是否正确理解 MariaDB 的局限性(情况似乎与 MySQL 相似)。
【问题讨论】:
-
日志表可能不需要 fk。
MariaDB's documentation about partitioning 将其限制之一列为,
- 分区表不能包含外键,也不能被外键引用。
在 DBMS 的上下文中,具有此类限制的表有什么用?我认为我从未见过没有通过外键关联表的数据库设计,所以我想知道我是否正确理解 MariaDB 的局限性(情况似乎与 MySQL 相似)。
【问题讨论】:
限制的原因是在内部每个分区都是它自己的 InnoDB 表,因此外键查找需要分散在所有这些上,而不是单个 1:1 查找。
InnoDB 引擎甚至不知道这些不是具有相同结构的独立表,而是它们在 SQL 级别上形成了一个分区表。同时外键检查仍然在引擎中实现,因此它们还不适用于分区表。
您可能仍希望使用分区表并为此牺牲服务器端参照完整性检查的原因很简单:性能权衡。
在 MariaDB 方面,我们有一个外键支持的功能请求,目前针对即将推出的 10.5 版本系列:
https://jira.mariadb.org/browse/MDEV-12483
但目前还不能 100% 确定它会在 10.5 之前及时发生。
在 MySQL 方面有:
https://dev.mysql.com/worklog/task/?id=148
但据我所知,它从 2009 年开始就没有任何明显的进展。
PS:我参与的项目中 FK 仅在开发和测试期间就位,而不是在实际的生产数据库中,假设在开发/测试期间可能已经出现并修复了可能的 FK 违规.. . 再次这样做是出于性能原因,因为 FK 检查需要时间...
【讨论】:
套用 jarlh 的话说,“也许不需要PARTITIONing。”
说真的,PARTITION 本质上并没有提供任何的性能增益。分区有用的主要情况,即删除“旧”数据,可能对日志表有用。这是您每天(或每周等)分区的地方,并使用DROP PARTITION 作为删除超过一周(或一个月或一年等)的数据的侵入性小得多的方式。然后执行REORGANIZE PARTITION 为“明天”(等)创建一个分区。
SELECT 不会通过分区来加速,除非在少数情况下。一种是当您需要“二维”索引时,例如地理意义上的“查找最近的”。 (但SPATIAL 是此类用例的可行竞争者。)
更多关于分区(或不分区):http://mysql.rjweb.org/doc.php/partitionmaint
【讨论】: