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

Question

Jeff Atwood wrote once он нашел запрашивающую базу данных для первичных ключей, а затем получение всех соответствующих полей с предложением IN удваивается так же быстро, как и его однострочный экземпляр.

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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