Это хорошая идея / подход для индексации столбца VARCHAR?


32

Мы используем PostgreSQL v8.2.3.

Здесь задействованы таблицы: EMPLOYEE и EMAILLIST .

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2 таблицы объединяются таким образом, что если EMPLOYEE.EMAIL1 или EMPLOYEE.EMAIL2 не имеют совпадающей записи, эти строки будут возвращены.

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

Колонка EMAILкоторый является VARCHAR (256) из EMAILLISTтаблицы индексируется. Теперь время отклика составляет 14 секунд.

Статистика подсчета таблиц: В настоящее время у EMPLOYEE есть 165 018 записей, а у EMAILLIST - 1 810 228 записей, и в будущем ожидается рост обеих таблиц.

  1. Это хорошая идея / подход для индексации столбца VARCHAR? Этот вопрос сразу же приходит мне в голову из-за причины, по которой мы ранее не индексировали столбец VARCHAR в нашем приложении. Совет экспертов / предложения по этому вопросу высоко ценятся.
  2. С этим текущим запросом и индексом время отклика 14 секунд является разумным или есть ли возможность для дальнейшей настройки? Каков опыт / мнение другого пользователя в зависимости от размера таблицы и времени ответа?

ПРИМЕЧАНИЕ. Мои действительные требования / варианты использования подробно описаны здесь .

Ответы:


25

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


Спасибо за ваш ценный комментарий. Есть ли возможность для дальнейшей настройки моего запроса в этом отношении, чтобы сократить время ответа с 14 секунд?
Гнанам

2
Без результатов EXPLAIN невозможно сказать, что оптимизировать. Версия 8.2.3 также устарела, вы должны перейти на более новую версию, вы на 4 года отстаете в обслуживании. Версии 8.3, 8.4 и 9.0 также быстрее во многих ситуациях. Лучшая статистика также помогает повысить производительность.
Фрэнк Хейкенс

5

Нет проблем с индексацией столбца varchar как такового

Проблема может возникнуть, когда у вас есть столбец varchar в виде FK в таблице с миллиардами строк. Тогда у вас будет суррогатный ключ для PK и FK, но вам все равно понадобится уникальное ограничение / индекс для естественного ключа varchar.

Ваши таблицы довольно малы, и производительность может быть связана с предложением OR. К сожалению, одна и та же проблема применяется независимо от того, как вы структурируете запрос (и я недостаточно знаком с PostgresSQL, чтобы извиниться)


0

Попробуйте избавиться от части запроса «OR e2.email IS NULL» и посмотрите, насколько быстро он выполняется. Если он работает быстрее, вы можете запустить его быстрее с «объединением всех»

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.