Mysql: оптимальный способ выполнения операции count (*) для столбца с низкой мощностью

1. Индексирование'valuationId 'рекомендуется делать здесь. Ожидая, что реализация BTree должна быть в состоянии обеспечить счет в порядке миллисекунд. (< 10 мс)

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

• Листовые блоки индекса имеют несколько указателей записей, которые читаются в чанках блока. [ 112]
• Количество дополнительных операций чтения блоков, необходимых для выделения листовых блоков, которые относятся к идентификатору оценки, является логарифмическим по отношению к общему количеству блоков.

Например, если размер блока равен 10, а 50 000 записей имеют идентификатор оценки, то необходимо прочитать около 5555 блоков. Сравните это как минимум с 500 000 блоков, которые нужно прочитать при сканировании таблицы. Очевидно, что у баз данных есть методы оптимизации, которые усложняют справедливое сравнение, и поэтому имеет смысл просто попробовать это.

2. Какие могут быть возможные недостатки, если таковые имеются, для индексации такого атрибута с низкой мощностью?

Роль мощности зависит от того, сколько записей данных уместится в одном блоке (т. е. < = recordsize / blocksize). Если это число приблизится к количеству элементов, то преимущество индекса исчезнет.

3. Каковы другие наилучшие подходы для получения счетчика (*).

Вы можете переоценить, насколько важно иметь точный счет, когда такой счет составляет порядка 50 000, и зная, что через секунду после того, как вы получите счет, возможно, уже были новые вставки / удаления. Имеет ли значение, действительно ли это 49 756, а не 49 695?

Если с приближением все в порядке, запустите запланированное пакетное задание, которое выполняет подсчет всех идентификаторов оценки и сохраняет его в отдельной таблице «подсчет» (в которой будет около 100 записей). В зависимости от ваших потребностей, вы можете запланировать его запуск один раз в день, в час, ... в зависимости от оборота и необходимой точности. Тогда у вас скорость молнии за счет незначительной неточности.

Чтобы повысить точность, вы можете объединить приведенную выше таблицу «count» с триггером вставки / удаления в таблицу данных, который бы вставил эффект этого изменения (в виде значения +1 или -1) в таблицу журнала. Тогда запрос количества записей будет использовать таблицу «count» в качестве отправной точки и изменить результат на основе этих значений + 1 / -1 в таблице журнала. Вышеуказанное задание будет очищать журнал при каждом запуске.