Oracle count (*) занимает слишком много времени

Question

Я пытался получить count(*) со стола, который содержит почти 7 миллионов записей и занимает больше часа для возвращения результата.

Также в таблице имеется 153 столбца, из которых индекс создан для столбца 123, поэтому попытался выполнить следующий запрос параллельно, но это не помогло.

select /*+ parallel (5) */ count(123) from <table_name> 

Просьба предложить, если есть альтернативный способ.

Когда я запустил desc на столе в жабе, на вкладке индекса указано значение no. строк. Любая идея, как это значение обновляется там?

Answer 1

Подсчет количества строк большой таблицы занимает много времени. Это естественно. В некоторых СУБД хранится количество записей, однако эти типы СУБД ограничивают параллелизм. Он должен заблокировать всю таблицу перед операцией DML в таблице. (Вся блокировка таблицы необходимо обновить отсчет должным образом.)

Значение в ALL_TABLES.NUM_ROWS (или USER_TABLES.NUM_ROWS) только статистическая информация, полученная с помощью analyze table ... или dbms_stats.gather_table_stats процедуры. Это неточность, а не информация в режиме реального времени.

Если вам не нужно точное количество строк, вы можете использовать статистическую информацию. Однако вы не должны зависеть от этого. Он используется оптимизатором Oracle, но не должен применяться в прикладной программе.

Я не уверен, почему вам приходится подсчитывать количество строк таблицы. Если вам это нужно в пакетной программе, которая выполняется нечасто, вы можете разбить таблицу, чтобы увеличить параллельность. Если вам нужен счет в онлайн-программе, вы должны найти способ не использовать счет.

Answer 2

select /*+ parallel (5) */ 

Похоже на нечетное число для степени параллелизма. Ну, очевидное 5 - это нечетное число, и это странно. DoP должны быть мощностью, кратным двум (подробнее см. Ниже).

Во всяком случае, есть ли у вас причина использовать параллельный запрос? У вас есть как минимум пять запасных процессоров? Если нет, есть хороший шанс, что накладные расходы на управление ведомыми устройствами PQ по меньшей мере способствуют низкой производительности.

---

Почему DOP = n * 2? Существует установленная эвристика, основанная на теории Queuing Theory, которая одновременно запускает более двух пакетных заданий, что приводит к снижению производительности. Find out more. (думаю, теория массового обслуживания фактически рекомендует цифру 1,8, но поскольку задания базы данных часто связаны с I/O или диском, мы обычно можем уйти с 2.)

Я изначально сказал «сила 2», но это в основном потому что многоядерные серверы имеют несколько процессоров, мощность которых равна 2, но несколько из них более точны, потому что в некоторых коробках есть 12 процессоров или какое-то другое число.

Теперь, если у нас есть 64-ядерный ящик, DOP 5 или 37 - это нормально, потому что у нас достаточно процессоров для одновременного запуска многих потоков. Но если у нас есть небольшой квадрат quadcore, только 2, 4 или 8 имеет смысл, потому что это единственные значения, которые обеспечат равномерное распределение работы для всех четырех процессоров. Выполнение пяти потоков на четырехъядерном ящике означает, что один процессор будет выполнять гораздо больше работы, чем другие три; есть вероятность, что потребуется больше времени для завершения, оставив остальных трех рабов.Таким образом, DOP=5 может фактически привести к большему истекшему времени, чем DOP=4.

DOP=n*2 - это только эмпирическое правило, а не камень. Однако он основан на здравых рассуждениях, и мы должны знать, почему мы делаем что-то другое. Очевидно, мы должны были провести некоторые эксперименты, чтобы подтвердить, что мы выбрали правильную ДОП (независимо от того, какое значение мы установим).

Answer 3

Несколько вопросов говоря:

1. Для «SELECT COUNT (*) из таблицы», чтобы использовать индекс, индексированный столбец должен быть не обнуляемым, или индекс должен быть тип растрового изображения.
2. Если в столбце известно, что в столбце нет нулей, но на нем нет нулевого ограничения, тогда используйте «select count (*) из таблицы, где column_name не равно null».
3. Разумеется, для сканирования индекса нужно быть более эффективным, чем таблица, но с таким количеством столбцов таблицы, вы, вероятно, прекрасно там.
4. Если вы действительно хотите сканирование параллельного индекса, используйте подсказку parallel_index, а не параллель. Но с 7 миллионами строк вам может не понадобиться параллелизм.
5. Вам нужно проверить план выполнения, чтобы увидеть, используется ли индекс и/или параллельный запрос.
6. Если вы можете использовать оценочное количество строк, то рассмотрим, используя пункт выборки: например, «выбрать 1000 * COUNT (*) из таблицы образца (0.1)»