Является ли запрос к базе данных MySQL information_schema хорошим способом поиска связанных таблиц?

Question

У меня есть таблица, на которую ссылаются внешние ключи во многих других таблицах. В моей программе, если я хочу удалить одну из этих строк, мне нужно сначала найти зависимости и представить их пользователю - «Этот объект зависит от x из таблицы y, z из таблицы q и т. Д.». Я также ожидаю, что число таблиц, имеющих внешние ключи к этой таблице, значительно возрастет со временем.

Является ли база данных information_schema хорошим способом поиска всех зависимостей? Я попытался запросить его, чтобы получить список всех таблиц, имеющих внешние ключи для моей таблицы, затем выполнить итерацию по результату и выбрать все записи в каждой таблице, где значение внешнего ключа соответствует значению, которое пытается удалить пользователь. У меня есть следующий запрос:

SELECT * FROM `KEY_COLUMN_USAGE` kcu
LEFT JOIN TABLE_CONSTRAINTS tc
ON tc.CONSTRAINT_NAME = kcu.CONSTRAINT_NAME
WHERE tc.CONSTRAINT_TYPE='FOREIGN KEY'
AND (kcu.REFERENCED_TABLE_SCHEMA='db')
AND (kcu.REFERENCED_TABLE_NAME = 'testtable')

, который идеально подходит для определения таблиц, в которых мне нужно искать, однако это очень медленно. Выполнение запроса в лучшем случае занимает от 1 до 2 секунд на моей машине для разработки, что значительно сократит время его запуска на рабочем сервере, но все равно будет довольно медленным.

Мне нужно знать, если это плохая идея - использовать information_schema таким образом. Если нет, как я могу извлечь лучшую производительность из запроса. Является ли запрос, который я использую, твердым или есть лучший способ сделать это? Если да, то как лучше решить эту проблему с точки зрения удобства обслуживания.

Answer 1

Дворжак прав, для этого предназначена INFORMATION_SCHEMA.

Что касается ваших проблем с производительностью, есть несколько способов улучшить производительность

• Легкий путь, но не так много улучшений: Сохраните информацию в статической переменной. По крайней мере, запрос будет выполняться только один раз на страницу

• Использование постоянного кэширования: вам может помочь альтернативный кеш PHP (см. http://fr3.php.net/manual/en/book.apc.php). Информация, которую вы получите из информационной схемы, является хорошим кандидатом для хранения в постоянном кэше.

• Используйте библиотеку ORM, такую ​​как doctrine (http://www.doctrine -project.org / ) Посмотрите на файл lib / Doctrine / Import / Mysql.php и вы увидите, что он делает именно то, что вам нужно, и многое другое.

Answer 2

Я тоже изучал это. Я хочу использовать KEY_COLUMN_USAGE для некоторых CRUD. И я заметил, что в этих таблицах нет ключей или индексов. Это может быть причиной плохой работы.

Answer 3

Я думаю, что именно для этого и предназначена INFORMATION_SCHEMA.

Answer 4

Использование INFORMATION_SCHEMA для этого нормально в статических или административных системах, но не рекомендуется для транзакционной прикладной функции, поскольку INFORMATION_SCHEMA, вероятно, реализовано как представления поверх словаря системных данных.

Это был бы довольно неэффективный способ сделать общую операцию 'D' для библиотеки CRUD. Кроме того, во многих системах (на ум приходит Oracle) словарь системных данных фактически реализован как представления структуры данных более низкого уровня. Это означает, что собственный словарь системных данных также может не подходить для этого. Словарь системных данных также может меняться от версии к версии.

Должно быть относительно немного случаев, когда прямое «удаление» записи и всех ее потомков - правильный путь. Выполнение этого как универсальной функции может принести вам немного практической пользы. Кроме того, если внешние ключи отсутствуют в базе данных, вы заставите детей-сирот лгать, так как этот подход зависит от присутствия FK, чтобы узнать, каких детей удалять.

Answer 5

В случае, если это когда-либо будет найдено в Google, также стоит отметить, что иногда information_schema отличается от того, что возвращает show create table.

Вот хороший пример этого потока обмена DBA Stack Exchange . После выполнения этой команды:

create table rolando (num int not null, primary key (num) using hash);

Проверить результаты:

mysql> show create table rolando\G
  (...)
  PRIMARY KEY (`num`) USING HASH

mysql> show indexes from rolando;
(...) | Index_type | (...)
(...) | BTREE      | (...)

Answer 6

Замедляет мои приложения для сканирования, но мне нужны данные ограничения внешнего ключа, чтобы все правильно соединить.

Задержки огромны при запросах к информационной схеме, и страница, которая раньше загружалась мгновенно, загружается за 3-4 секунды.

Ну, по крайней мере, ограничения внешнего ключа доступны в MySQL 5, что делает разработку приложений более надежной, но, очевидно, дорогой.

Люди жаловались на эту проблему с 2006 года, основываясь на моих поисках в Google, и проблема остается - не должно быть легко исправить; - (