Какая польза от таблицы, которая не может содержать и ссылаться на внешние ключи?

Question

В документации MariaDB о секционировании перечислено одно из его ограничений:

• Секционированная таблица не может содержать или ссылаться на внешние ключи.

В контексте СУБД, что может быть использование таблицы с такими ограничениями? Я не думаю, что когда-либо видел дизайн БД без связи таблиц через внешние ключи, поэтому мне интересно, правильно ли я понимаю ограничения MariaDB (ситуация выглядит аналогично MySQL).

Answer 1

Причина ограничения заключается в том, что внутренне каждый раздел является собственной таблицей 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-проверки требуют своего времени ...

Answer 2

Перефразируя ярла, «Возможно, нет необходимости в PARTITIONing.»

Серьезно, PARTITION по сути не обеспечивает какого-либо прироста производительности. Основной случай, когда разбиение полезно, а именно удаление «старых» данных, может быть полезным для таблицы журнала. Здесь у вас есть ежедневные (или еженедельные и т. Д. c) разделы, и вы используете DROP PARTITION как намного менее инвазивный способ удаления данных старше недели (или месяца или года, и т. Д. * 1022). *). А затем выполните REORGANIZE PARTITION, чтобы создать раздел для «завтра» (et c).

SELECT не ускоряется путем разбиения, за исключением нескольких редких сценариев ios. Один из них - когда вам нужен «двумерный» индекс, такой как «найти ближайший» в географическом смысле. (Но SPATIAL является жизнеспособным претендентом на такой вариант использования.)

Подробнее о разбиении (или нет): http://mysql.rjweb.org/doc.php/partitionmaint