Что такое Big-O для SQL select?

поскольку вы не контролируете выбранный алгоритм, нет никакого способа узнать напрямую. Однако без индексов выбор должен быть O (n) (сканирование таблицы должно проверять каждую запись, что означает, что она будет масштабироваться с размером таблицы).

с индексом A SELECT, вероятно, O(log (n)) (хотя это будет зависеть от алгоритма, используемого для индексирования, и свойств самих данных, если это верно для любой реальной таблицы). Чтобы определить результаты для любой таблицы или запроса, необходимо прибегать к профилированию реальных данных, чтобы быть уверенным.

вставка без индексов должна быть очень быстрой(близко к O (1)), в то время как обновление должно сначала найти записи, и поэтому будет медленнее (немного), чем выбор, который вас туда доставит.

вставка с индексами, вероятно, снова будет находиться в поле O(log(n^2)), когда дерево индексов должно быть перебалансировано, ближе к O(log (n)) в противном случае. Такое же замедление произойдет с обновлением, если оно влияет на индексированные строки, поверх Выберите затраты.

все ставки отключены, как только вы говорите о присоединении к миксу: вам нужно будет профилировать и использовать инструменты оценки запросов баз данных, чтобы прочитать его. Также обратите внимание, что если этот запрос критичен по производительности, вы должны reпрофиль время от времени, как алгоритмы, используемые оптимизатором запросов будет меняться по мере изменения загрузки данных.

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

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