Стоит ли запрашивать первичные ключи?

Question

Джефф Этвуд однажды написал , он обнаружил, что запрашивает базу данных для первичных ключей, а затем получение всех соответствующих полей с предложением IN в два раза быстрее, чем его аналог из одного sql.

Интересно, относится ли это ко всем ситуациям, и если нет, то в каких случаях это все еще дает значительные возможности для улучшения производительности?

Кроме того, как дорого обходится доступ к БД через библиотеку языка сценариев? Я в основном говорю об очень известной комбинации PHP-MySQL.

Answer 1

Это зависит. Иногда, как ясно показывает сообщение в блоге Джеффа, это может обеспечить (значительное) повышение производительности. Но, как правило, лучше позволить оптимизатору запросов найти наилучший план выполнения, а затем попытаться вручную оптимизировать особенно медленные запросы.

Из статьи: «Мы по умолчанию используем встроенные языковые конструкции Linq и перейдем к ручной настройке старых SQL-объектов, где трассировки производительности говорят нам, что нам нужно». Точно так же вы должны по умолчанию оптимизатор запросов делать то, что он делает, и перейти к ручной настройке ваших операторов SQL, где трассировки производительности говорят вам, что вам нужно.

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

Answer 2

Джефф Этвуд говорит о SQL Server, а не о MySQL. Оптимизация SQL, как известно, зависит от СУБД, конфигурации, запроса, данных и состояния кэша. Если не считать, что выбор только полей первичного ключа будет, по крайней мере, таким же быстрым, как выбор всей строки, обобщить сложно. Конечно, трудно обобщить в какой-либо степени, что было бы полезно. Вам нужно будет сравнить ваш конкретный случай.

Исходя из моего опыта работы с MySQL, я был бы удивлен, если бы выбор деталей с запросом IN выполнялся быстрее, чем выполнение SELECT * в первую очередь. Насколько я понимаю, SELECT * дороже, чем SELECT id, потому что MySQL должен искать данные индекса в обоих случаях, но в первом случае необходимо выполнить дополнительный шаг выборки данных, составляющих остальную часть строки, что может потребовать дополнительного поиска на диске (тем более что данные таблицы с меньшей вероятностью будут в кеше, чем индекс). Однако с кластеризованным индексом InnoDB (первичным ключом будет, если вы используете InnoDB), существует особый случай, когда данные хранятся вместе с записью индекса в кластерном индексе. Я полагаю, что в этом случае скорость SELECT * будет почти такой же, как у SELECT id.

Answer 3

Получение данных с помощью ключа всегда будет быстрее при извлечении данных из таблицы. Это просто, как работают базы данных; захват индексированных данных происходит быстрее, чем захват неиндексированных данных. И получение только ключа может быть быстрее, поскольку все, что нужно ядру БД, - это «развернуть» данные из индекса в набор результатов.

Что касается вашего "дорогого" вопроса, я предполагаю, что вы имеете в виду "это медленно". Я не обнаружил, что это так. Одна из самых дорогих, с точки зрения вычислений, частей запроса открывает соединение, и большинство (если не все) современные базы данных используют ту или иную форму кэширования соединения, так что это уже не так дорого. Что касается самих запросов, единственная реальная нагрузка - это задержка в сети, поэтому вы должны увидеть, что запросы занимают примерно то же время или не намного дольше, чем если бы вы запрашивали язык без сценариев (другими словами, миллисекунды).