Поскольку вы не контролируете выбранный алгоритм, вы не можете узнать напрямую. Однако без индексов значение SELECT должно быть равно O (n) (сканирование таблицы должно проверять каждую запись, что означает, что она будет масштабироваться в соответствии с размером таблицы).
С индексом SELECT, вероятно, равен O (log (n)) (хотя это будет зависеть от алгоритма, используемого для индексации, и свойств самих данных, если это верно для любой реальной таблицы). Чтобы определить свои результаты для любой таблицы или запроса, вам нужно прибегнуть к профилированию данных реального мира, чтобы быть уверенным.
INSERT без индексов должен быть очень быстрым (близко к O (1)), в то время как UPDATE необходимо сначала найти записи и поэтому будет медленнее (немного), чем SELECT, который доставит вас туда.
INSERT с индексами, вероятно, снова будет в приблизительной точке O (log (n ^ 2)), когда дерево индексов необходимо перебалансировать, в противном случае ближе к O (log (n)). Такое же замедление будет происходить с UPDATE, если оно влияет на проиндексированные строки, в дополнение к затратам SELECT.
Все ставки отменяются, когда вы говорите о JOIN в миксе: вам придется профилировать и использовать свои инструменты оценки запросов к базам данных, чтобы прочитать их. Также обратите внимание, что если этот запрос критичен к производительности, вы должны время от времени профилировать re , так как алгоритмы, используемые оптимизатором запросов, будут меняться при изменении загрузки данных.
Еще одна вещь, которую нужно иметь в виду ... big-O не говорит вам о фиксированных затратах на каждую транзакцию. Для небольших таблиц они, вероятно, выше, чем фактические затраты на работу. Например, затраты на установку, разбор и коммуникацию межсетевого запроса для одной строки, безусловно, будут больше, чем поиск индексированной записи в небольшой таблице.
Из-за этого я обнаружил, что возможность связать группу связанных запросов в один пакет может оказать гораздо большее влияние на производительность, чем любая оптимизация, которую я сделал для собственно базы данных.