Я бы сказал, что тестирование необходимо, но приятно знать опыт других людей. По моему опыту на сервере MS SQL, нулевые значения могут вызывать серьезные проблемы с производительностью (различия). В очень простом тесте теперь я видел возвращение запроса через 45 секунд, когда в соответствующих полях в операторе create таблицы было установлено значение NULL, и более 25 минут, когда оно не было установлено (я перестал ждать и просто набрал максимум примерный план запроса).
Тестовые данные - это 1 миллион строк x 20 столбцов, которые составлены из 62 случайных строчных букв в алфавитном порядке на i5-3320 обычном HD и 8 ГБ ОЗУ (SQL Server использует 2 ГБ) / SQL Server 2012 Enterprise Edition на Windows 8.1. Важно использовать случайные данные / нерегулярные данные, чтобы сделать тестирование реалистичным «худшим» случаем. В обоих случаях таблица была воссоздана и перезагружена со случайными данными, что заняло около 30 секунд в файлах базы данных, в которых уже было подходящее количество свободного места.
select count(field0) from myTable where field0
not in (select field1 from myTable) 1000000
CREATE TABLE [dbo].[myTable]([Field0] [nvarchar](64) , ...
vs
CREATE TABLE [dbo].[myTable]([Field0] [nvarchar](64) not null,
по соображениям производительности оба параметра таблицы data_compression = page set были установлены, а все остальное было по умолчанию. Нет индексов.
alter table myTable rebuild partition = all with (data_compression = page);
Отсутствие нулей - это требование для таблиц, оптимизированных для памяти, для которых я специально не использую, однако sql-сервер, очевидно, будет делать то, что быстрее всего, что в данном конкретном случае, как представляется, массово в пользу отсутствия нулей в данных и использования не ноль на столе создать.
Любые последующие запросы той же формы в этой таблице возвращаются через две секунды, поэтому я предполагаю, что стандартная статистика по умолчанию и, возможно, наличие таблицы (1,3 ГБ) вписывается в память, работают хорошо.
т.е.
select count(field19) from myTable where field19
not in (select field18 from myTable) 1000000
Кроме того, если нет нулевых значений и нет необходимости иметь дело с нулевыми случаями, это делает запросы намного проще, короче, менее подвержено ошибкам и, как правило, быстрее. Если это вообще возможно, лучше избегать значений NULL, как правило, на сервере MS SQL, по крайней мере, если они явно не требуются и не могут быть разумно решены из решения.
Начиная с новой таблицы и определяя ее размер до 10 м строк / 13 ГБ, тот же запрос занимает 12 минут, что очень неплохо, учитывая аппаратное обеспечение и отсутствие используемых индексов. Информационный запрос был полностью связан с вводом-выводом и зависанием между 20 и 60 Мбит / с. Повторение того же запроса заняло 9 минут.