Следуя большей части вашего совета, мы не увидели никаких улучшений по сравнению с простым созданием массивной строки и передачей ее партиями ~ 100-1000 строк с окружающей транзакцией. мы обошли
* Метод большой строки [5000rows в 500batch]: 1716ms = ~ 2914rows в секунду.
(это дерьмо!).
Наша база данных находится на виртуальном хосте с одним процессором (i7 снизу), а схема таблицы:
CREATE TABLE
archive_account_transactions
(
account_transaction_id INT,
entered_by INT,
account_id INT,
transaction_type_id INT,
DATE DATETIME,
product_id INT,
amount float,
contract_id INT NULL,
note CHAR(255) NULL
)
с четырьмя индексами на account_transaction_id (pk), account_id, DATE, contract_id.
Просто подумал, что сначала я оставлю несколько комментариев, к которым мы подключаемся:
jdbc:sybase:Tds:40.1.1.2:5000/ikp?EnableBatchWorkaround=true;ENABLE_BULK_LOAD=true
мы также попробовали синтаксис .addBatch, описанный выше, но он был немного медленнее, чем просто использование java StringBuilder для создания пакета в sql вручную, а затем просто выдавить его в одном операторе execute. Удаление имен столбцов в операторе вставки дало нам удивительно большой прирост производительности, которое, казалось, было единственным, что фактически влияло на производительность. Поскольку параметр Enable_bulk_load, похоже, не оказал на него никакого влияния, а также EnableBatchWorkaround, мы также попробовали DYNAMIC_PREPARE = false, что звучало многообещающе, но, похоже, ничего не делало.
Любая помощь в налаживании этих параметров была бы великолепна! Другими словами, есть ли какие-нибудь тесты, которые мы могли бы запустить, чтобы убедиться, что они действуют? Я по-прежнему убежден, что эта производительность не близка к расширению границ sybase, так как mysql из коробки делает больше, чем 16 000 строк в секунду, используя тот же «метод больших строк» с той же схемой.
Приветствие
Rod