Коротко — затем подробнее и с практическими рекомендациями.

Результат запроса
SELECT c.region, SUM(o.amount)
FROM Orders o
JOIN Customers c ON o.customer_id = c.customer_id
WHERE o.amount > 100
GROUP BY c.region
HAVING COUNT(*) > 10;

зависит от того, как СУБД отфильтрует строки Orders, как выполнит join и как выполнит агрегацию. Неправильные индексы/статистика → медленный план; конкурентные транзакции и особенности арифметики → «ошибки» в суммах/количестве.

1) Какие индексы нужны (практические рекомендации)

Orders:

Индекс, поддерживающий WHERE o.amount > 100 и покрывающий доступные поля. Например (в синтаксисе SQL Server/Postgres/MySQL):B-tree индекс с лидирующей колонкой amount: (amount, customer_id, order_id) или просто (amount, customer_id).Цель: быстро отфильтровать строки по amount и иметь customer_id для join и amount для SUM без обращения к основному ряду (covering index).Альтернативно: если фильтр amount мало селективен, но join по customer_id выгоднее (много заказов по одному customer_id или требуется быстро найти все заказы клиента), используйте индекс (customer_id, amount).Если часто группируете/агрегируете по customer_id, можно создать агрегирующие/материализованные представления (indexed/materialized view) с суммами и счетчиками по customer_id или region.

Customers:

Убедиться, что есть индекс/PK на customer_id (обычно есть).Для быстрого доступа к region без обращения к таблице: покрывающий индекс (customer_id, region) или кластерный индекс по customer_id (в InnoDB PK содержит region, если region хранится в строке).Если много различных region и агрегирование выгодно делать по region, индекс по region не мешает, но сам по себе он не решит проблему соединения (полезен для merge-агрегации, если доступ к customers упорядочен по region).

Дополнительно:

Если запрос часто выполняется и данные не сверх-динамичные — материализованный вид (sum/count per customer_id or per region for amount>100) с индексом по region.Партиционирование таблицы Orders по диапазону amount (или по диапазону дат, если amount не хорош для партиц.) — для очень больших таблиц партицирование уменьшит объем сканируемых партиций.

2) Какие статистики нужны и почему

Актуальные статистики по колонкам:
Orders.amount — распределение значений (histogram), чтобы оптимизатор понял селективность WHERE amount > 100.Orders.customer_id — частота (ndv, most-common values — heavy hitters). Если небольшой набор «тяжёлых» клиентов, оптимизатор должен это знать.Customers.region — карточность регионов (для оценки размера групп).Мультиколоночные/сквозные статистики:
Статистика по (amount, customer_id) или расширенные статистики (Postgres CREATE STATISTICS, SQL Server histogram/extended) — если есть корреляция между amount и customer_id.Регулярное обновление статистик (ANALYZE, UPDATE STATISTICS) — устаревшие статистики приводят к плохим планам (full scan вместо индекса и наоборот).Для DWH/OLAP полезны более точные гистограммы и статистики по распределению сумм (skew), чтобы корректно рассчитывать стоимость агрегаций/хешей.

3) Какие источники «ошибок» агрегации (почему SUM/COUNT могут выглядеть неверными)

Конкурентные транзакции и изоляция (см. ниже) — видимые данные могут меняться, вы можете «увидеть» незакоммиченные или частично закоммиченные изменения.Плавающая точка (FLOAT/DOUBLE):
Накопление сумм в произвольном порядке даёт разные погрешности из‑за неассоциативности операции сложения; параллельная агрегация (частичные суммы) может давать немного другие результаты.Для финансовых сумм лучше DECIMAL/NUMERIC.Переполнение типов:
Если суммарное значение превосходит тип (например INT), то будет overflow/ошибка/неожиданный результат.NULL-значения: SUM игнорирует NULL; COUNT(*) считает строки; COUNT() считает не-NULL.Дублирование строк:
Неправильный join (например отсутствуют уникальные ключи/неверная связь) может приводить к умножению строк → завышенные суммы/счёты.Некорректные агрегаты при использовании приближённых/семплированных методов (approx_count, hyperloglog, статистические выборки) — они дают приближённый результат.Странности при параллельном исполнении: частичные агрегаты собираются в разном порядке -> плавающие ошибки для float.

4) Почему результаты могут отличаться при разных уровнях изоляции транзакций
Ключевые понятия: грязное чтение (dirty read), неповторяемое чтение (non‑repeatable read), фантомы (phantom reads), сериализуемость. Разные СУБД реализуют это по-разному (MVCC против lock-based). Примеры влияния:

READ UNCOMMITTED (грязные чтения):
Можно прочитать незакоммиченные изменения другой транзакции. Если другая транзакция вставила/изменила Orders и потом откатила, ваш SUM/COUNT могли временно включить те строки → неверный результат.READ COMMITTED:
Устраняет грязные чтения — вы видите только закоммиченные изменения. Но если другая транзакция закоммитит новые строки в процессе выполнения вашего большого запроса, вы можете увидеть их (зависит от реализации): результат запроса может включать строки, которые появились в середине выполнения — в итоге итоговый набор отражает состояние данных в момент чтения каждой страницы/блока.В СУБД с MVCC (Postgres) читатель в READ COMMITTED видит snapshot каждой отдельной команды — внутри одного оператора SELECT обычно используется один snapshot, но для сложных планов могут быть отличия между версиями СУБД.REPEATABLE READ / SNAPSHOT:
Обычно клиент видит консистентный снимок данных, сделанный в начале транзакции (или в начале оператора в некоторых реализациях): один и тот же запрос в течение транзакции даст стабильный результат, даже если другие транзакции коммитят изменения. Для одного запроса это означает детерминированность относительно snapshot.SNAPSHOT защищает от грязных/неповторяемых чтений и фантомов в плане чтения данных, но не гарантирует полную сериализуемость (возможны write skew), если это не «serializable» уровень.SERIALIZABLE:
Гарантирует поведение, эквивалентное последовательному выполнению транзакций. Для агрегирующих запросов означает, что вы не увидите эффектов конкурирующих транзакций, которые изменяют реляцию так, чтобы повлиять на ваше агрегирование; СУБД может блокировать/откатывать конкурирующую транзакцию, чтобы сохранить сериализуемость.Часто приводит к блокировкам/конфликтам и возможным откатам (серийные конфликты).

Конкретные сценарии отличия:

Пока вы выполняете большой агрегирующий запрос, другая транзакция вставляет 20 новых Orders с amount>100 для конкретного региона.
Под READ UNCOMMITTED: вы можете посчитать их, даже если вставка позже откатится → неверная сумма.Под READ COMMITTED: в зависимости от момента чтения вы можете увидеть некоторые из них (неустойчивость), итог может быть «частично» включающим новые строки.Под SNAPSHOT/REPEATABLE READ (statement snapshot): весь запрос видит состояние на момент старта запроса → вы либо увидите их все (если они были закоммичены до старта), либо не увидите вовсе.Под SERIALIZABLE: одна из транзакций может быть откатена, чтобы обеспечить консистентность.

Еще: если оптимизатор использует несколько этапов (параллельные воркеры) и часть данных читается с разными snapshot-версиями в lock-based СУБД, можно получить непредсказуемые результаты при низких уровнях изоляции.

5) Практические действия для ускорения и повышения корректности

Создайте/проверьте индексы:
idx_orders_amount_customer (amount, customer_id) — для фильтра + covering.idx_customers_id_region (customer_id, region) — покрывающий join.Обновите статистику (ANALYZE / UPDATE STATISTICS) и при необходимости создайте гистограммы для amount.Проверьте селективность amount>100: если селективность низкая — индекс не поможет (полный скан будет дешевле).Используйте материализованное представление (или агрегированную таблицу) если запрос выполняется часто: pre-aggregate by customer or region for amount>100 and refresh periodically or use incremental maintenance.Для точных финансовых сумм: используйте DECIMAL/NUMERIC, не FLOAT.Если нужны консистентные результаты при конкуренции — используйте SNAPSHOT/REPEATABLE READ или SERIALIZABLE; если боитесь откатов под SERIALIZABLE — используйте повторение транзакции в приложении.Инспектируйте планы (EXPLAIN, EXPLAIN ANALYZE), смотрите, используется ли индекс, сколько строк оценивает оптимизатор vs реально, и корректируйте статистику/индексы.

6) Короткие рекомендации по выбору индекса в зависимости от условий

Если amount>100 очень селективен (мало строк): индекс (amount, customer_id) — лучший выбор.Если amount>100 малоселективен (много строк), но у большинства заказов customer_id небольшое число клиентов (скью), выгоднее агрегировать по customer_id: индекс (customer_id, amount) или предварительная агрегация по customer.Для больших таблиц подумайте о партицировании по логическому ключу (дата, диапазон amount) и о materialized view.

Если нужно — могу:

Предложить конкретные CREATE INDEX для вашей СУБД (Postgres / MySQL / SQL Server / Oracle).Рассчитать примерный план и оценить выгоду индекса на тестовой выборке (покажите размер таблиц и распределение amount/customer_id).