Запись строки, которая содержит “”

Предложение ON CONFLICT REPLACE заставит SQLite удалить существующие строки, а затем вставить новые строки. Это означает, что SQLite, вероятно, собирается потратить некоторое время

• , удаляя существующие строки
• , обновляя индексы
• , вставляя новые строки
• обновляя индексы

Это мое мнение, основанное на документации SQLite и прочтении о других системах управления базами данных. Я не смотрел на исходный код.

SQLite имеет два способа выражения ограничений уникальности: PRIMARY KEY и UNIQUE. Они оба создают индекс, хотя.

Здорово, что вы сделали тесты. Большинство разработчиков не делают этого. Но я думаю, что ваши результаты теста вводят в заблуждение.

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

Если он не должен давать правильных ответов, я могу сделать это действительно, очень быстро.

Чтобы получить значимое время для вставки в таблицу без ключа, вам нужно либо

• запустить код , прежде чем вставить новые данные, чтобы убедиться, что вы этого не сделаете. нарушите необъявленное ограничение первичного ключа и убедитесь, что вы обновляете существующие строки правильными значениями (вместо вставки), или
• запускаете код после вставки в эту таблицу для очистки дубликатов на (Fld0, Fld2, Fld3) и для урегулирования конфликтов

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

Кстати, я выполнил тест, запустив в вашу схему операторы вставки SQL по 100 тыс. Транзакций по 1000 операторов, и это заняло всего 30 секунд. Одна транзакция из 1000 операторов вставки, которая, по-видимому, соответствует ожидаемой при производстве, заняла 149 мсек.

Может быть, вы можете ускорить процесс, вставив во временную таблицу без ключа, а затем обновив таблицу с ключами.