Когда таблица базы данных становится достаточно большой, что индекс выгоден?
Откат важен даже в случае неудачной фиксации, в соответствии с документами Java 1.6 JDBC :
Настоятельно рекомендуется, чтобы приложение явно зафиксировало или откатило активную транзакцию до для вызова метода close. Если вызывается метод close и существует активная транзакция, результаты определяются реализацией.
Это означает, что если вы явно не вызываете откат, некоторые реализации JDBC могут вызвать коммит до закрытия соединения.
Еще одна веская причина для отката, как предложил Xepoch, и при использовании пула соединений это еще более важно. При получении соединения из пула соединений большинство реализаций выполнят connection.setAutoCommit(defaultAutoCommit) перед тем, как дать вам соединение, и в соответствии с JavaDocs:
Если этот метод вызывается во время транзакции и режима автоматической фиксации изменено, транзакция совершена
Если connection.rollback() выдает исключение - тогда это сложная задача ...
9 ответов
Для запросов, включающих небольшие части строк таблицы, всегда полезны индексы, будь то 100 строк или 1 000 000 .
См. Это запись в моем блоге для примеров с планами и деталями производительности:
Запросы, подобные этому:
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
, скорее всего, будут использовать HASH JOIN . Будет создана хеш-таблица для меньшей таблицы, и строки из большей таблицы будут использоваться для проверки хеш-таблицы.
Для этого индекс не требуется.
Однако этот запрос:
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
WHERE t1.othercol = @value
будет использовать NESTED LOOPS : строки из внешней таблицы ( table1 ) будут найдены с использованием индекса в table1.othercol , а строки из внутренней таблицы ( table2 ) будет выполняться поиск с использованием индекса на table2.col .
Обратите внимание, что даже если у вас нет индекса, оптимизатор может выбрать Eager Spool вашу небольшую таблицу, что означает создание временного индекса на время выполнения запроса и удаление индекса после запрос завершен.
Если запрос небольшой, он будет очень быстрым, но, опять же, индекс не повредит (я имею в виду запросы SELECT ). Если оптимизатору он не понадобится, он просто не будет использоваться.
Обратите внимание, что создание индекса может повлиять на производительность DML , но это уже другая история.
SELECT ). Если оптимизатору он не понадобится, он просто не будет использоваться.
Обратите внимание, что создание индекса может повлиять на производительность DML , но это уже другая история.
SELECT ). Если оптимизатору он не понадобится, он просто не будет использоваться.
Обратите внимание, что создание индекса может повлиять на производительность DML , но это уже другая история.
Индекс почти всегда увеличивает производительность запроса за счет дополнительной памяти и снижения производительности для вставки / удаления (поскольку в этой точке необходимо поддерживать индекс). Профилирование будет единственным определенным способом определить, полезен ли индекс в вашем конкретном случае.
Как правило, вы жертвуете памятью на скорость при создании индекса (кроме дополнительных затрат на вставку) . Если вы выполняете много запросов (выбирает или обновляет) относительно количества вставленных / удаленных строк, индексы почти всегда будут повышать вашу производительность.
, это зависит от селективности ваших данных, если ваши данные недостаточно избирательны, то index может даже не использоваться, так как стоимость будет слишком высокой. Если у вас есть только 2 значения в таблице и эти значения распределены равномерно, тогда вы получите сканирование, а не поиск
Я все еще считаю, что каждая таблица должна иметь первичный ключ, если он у вас есть, то у вас уже есть индекс
Штраф за вставку будет незначительным до тех пор, пока не появится преимущество индексов. Оптимизатор достаточно умен, чтобы в любом случае игнорировать индексы до тех пор, пока не появится этот момент. Поэтому просто проиндексируйте таблицу с самого начала.
Еще одна вещь, о которой следует подумать, - это концепция производительности кодирования - иногда наличие индекса может упростить умственные издержки, связанные с размышлениями о том, как управлять отношениями между различными частями данных. иногда это может его усложнить ...
Независимо от размера, использование индекса при поиске всегда дает преимущество в производительности.
Что касается накладных расходов, возникает вопрос: какие накладные расходы вы имеете в виду и как вы относитесь к этому это значение поиска? В конце концов, это разные ценности.
Есть две формы накладных расходов для индекса: пробел (который обычно незначителен, в зависимости от структуры индекса) и повторный индекс при вставке (сервер должен пересчитывать индекс после каждой вставки).
Как я уже упоминал, проблема с космосом, вероятно, не такая уж большая проблема. Но повторная индексация - это . К счастью, вам нужно делать много почти непрерывных вставок, прежде чем такая форма накладных расходов станет проблемой.
Итог: вам почти всегда лучше иметь индекс. Начните с этой позиции и подождите, пока повторная индексация не станет узким местом. Затем вы можете изучить альтернативы.
Очень полезная ссылка: "Ответы на вопрос о переломном моменте" http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Tipping-Point-Query-Answers.aspx
Лучше всего позволить серверу решить это самостоятельно. Вы создаете индекс в столбцах, где это имеет смысл (я уверен, что есть целые главы, если не книги о том, как сделать это наилучшим образом), и позволяете серверу SQL выяснить, когда и как использовать индекс.
Во многих случаях , при оптимизации вам нужно будет прочитать документацию вашей конкретной СУБД, чтобы узнать больше о том, как она использует индексы, и связать это с запросами, которые использует оптимизируемое приложение. Затем вы можете точно настроить использование индекса.
Я считаю, что как только вы начнете выполнять соединения по этим полям типа int, ваша таблица станет достаточно большой. Если таблица достаточно мала, чтобы не использовать индекс, то накладные расходы не будут настолько значительными, чтобы вы захотели отказаться от нее.
Когда я думаю о накладных расходах, связанных с индексом, я обычно рассматриваю, как часто индекс таблицы будет изменяться - путем вставки, удаления и обновления индексированных столбцов.