У меня есть таблица с тремя столбцами. Первый столбец, определенный как тип varchar
, — это номер клиента (c_number
), два других также типа varchar
— имя и фамилия клиента (c_first_name
и c_last_name
).
Таблица не имеет отдельного первичного ключа. Но есть дубликаты с одинаковым столбцом c_number
(например, для тех же клиентов, но имена и фамилии записаны в разных регистрах).
Количество строк в таблице довольно велико — около миллиона.
Необходимо отобразить всех клиентов, номер которых дублируется более N раз.
Вот код, который решает проблему в лоб:
SELECT *
COUNT(c_number) AS c
GROUP BY
c_number
HAVING
(c > N) ;
Но этот подход кажется очень медленным. Мое решение состоит в том, чтобы добавить индекс:
CREATE INDEX idx_c_number
ON TABLENAME(c_number);
После этого, если я правильно понимаю, можно будет выполнять выражения для поиска дубликатов в реальном времени.
Если это все еще не так, подскажите, пожалуйста, лучшее решение для поиска дубликатов с наилучшей производительностью (учитывая тот факт, что у нас все еще нет первичного ключа).
Собственно, "миллион записей" уже не считается "большим"...
Да, индекс позволит вам использовать запрос, подобный описанному вами, с разумным улучшением скорости. «Но ценой…»
Хотя некоторые люди считают «необходимым» или, по крайней мере, «привычным» иметь первичный ключ в таблице, на самом деле это зависит от вас. Некоторые таблицы, например, в основном являются просто «журналами событий или транзакций», и вы никогда не будете использовать «первичный ключ» для ссылки на них. Если вы никогда не будете использовать его, он вам не нужен. В любом случае это не повлияет на «индексацию».
Теперь, создавая этот индекс, вы вводите долгосрочные затраты: отныне индекс необходимо поддерживать. Это приведет к дополнительной стоимости всего, что вставляет или удаляет запись или обновляет проиндексированное значение. Итак, хотя это, конечно, сделает текущий запрос «быстрее», это не бесплатно. «Планируйте соответственно». Только вы можете решить, что лучше для вас. Из-за более серьезных последствий я рекомендую вам обсудить этот вопрос с вашими коллегами, прежде чем продолжить.
Создайте ограничение первичного ключа.