Простой
пример
29
select txid,amount,curr
from transactions
where accountid=?
and txdate >= date_sub(?, interval 30 day)
order by txdate
Мы всего лишь берем данные из одной таблицы для заполнения другой .
Если нам нужен отсортированный результат, мы добавим оператор order
by
в запрос, который получает данные из итоговой таблицы для предо-
ставления конечному пользователю . На нынешнем, промежуточном,
этапе оператор order by не нужен; это очень распространенная ошибка,
заметить ее можно только наметанным взглядом .
Второе усовершенствование связано с частой вставкой данных со средней
скоростью (я получил в общей сложности несколько сотен строк в табли-
це журнала) . По умолчанию для соединения JDBC применяется режим
автоматической фиксации изменений . В данном случае это означает,
что после каждой вставки будет срабатывать принудительный опера-
тор commit и каждое изменение будет синхронно записываться на диск .
Такая запись в постоянное хранилище гарантирует, что
изменения не
будут потеряны даже в случае сбоя системы всего через миллисекунду
после их внесения, а без фиксации изменения хранятся только в памяти
и поэтому могут быть потеряны . В данном случае это излишняя предо-
сторожность . Если произойдет сбой системы, можно просто запустить
программу снова, особенно если удастся сделать ее быстрой – маловеро-
ятно, что сбои будут происходить очень часто . Поэтому я вставил в на-
чале программы оператор, отключающий автоматическую фиксацию,
а в конце – оператор, принудительно фиксирующий изменения:
// Отключение
автоматической фиксации
con.setAutoCommit(false);
и
con.commit();
Эти два очень маленьких изменения дали некоторое ускорение работы
программы: их совместный эффект на версии для MySQL увеличил ско-
рость примерно на 10% . Однако с Oracle и SQL Server мы не получили
никаких заметных результатов (табл . 1 .3) .
Таблица 1.3. Коэффициент увеличения скорости после добавления
индекса к транзакциям, очистки кода и отключения автоматической
фиксации изменений
Достарыңызбен бөлісу: