Объединения в целочисленных столбцах более эффективны, чем объединения в varchar в Postgresql?
Я слышал / читал предположение, что объединения в целочисленных столбцах более эффективны, чем объединения в столбцах varchar. Иногда я слышал, что это квалифицировано так: "объединения в целочисленных столбцах более эффективны, чем объединения в длинных столбцах varchar".
Кто-нибудь может прокомментировать, является ли какое-либо утверждение верным, и если да, то какие из основных причин?
любые статьи или ссылки приветствуются и приветствуются. Спасибо!
3 ответа
Я не знаком с Postgresql, но я ожидаю, что это будет верно для любой базы данных по той простой причине, что сравнение целых чисел намного эффективнее, чем сравнение строк.
Для выполнения объединения в базе данных необходимо выполнить поиск по индексу по ключевому полю. Поиск по целочисленному индексу должен быть быстрее, чем поиск по строковому индексу. Мало того, что задействовано меньше данных, сравнение может быть выполнено молниеносно в одной операции ЦП, а не какое-то сложное сравнение строк, которое использует чувствительность к регистру и логику локализации.
Это предполагает, что под "более эффективным" вы подразумеваете преимущество в скорости на микросекунду. Конечно, могут быть архитектурные соображения, которые означают, что создание объединения в строке в целом является лучшим решением для проектирования базы данных. Но в целом я избегаю присоединяться к чему-либо, кроме целых чисел.
В этом сообщении было обнаружено, что строковые объединения занимают на 35–100% больше процессорного времени, чем целочисленные объединения (на SQL Server), в зависимости от размера строкового столбца и от того, проиндексированы ли столбцы. Разница в затраченном времени была меньше (4% - 20%). Как отмечает автор, YMMV - вы должны проверить свой собственный случай, чтобы увидеть, если есть существенная разница.
Это верно, и потому, что во внутренних процессорах ЦП сравнения строк удивительно сложны.