Возможно первый раз идет чтение с диска, затем из кэша, т.е. из памяти. Если так, то просто сделать первый запуск в холостую, т.е. планировщик при старте ОС запускает какую-то прогу, которая обращается к базе.

Железо опиши. В нем проблема. Но по описанным симптомам просто достаточно сделать один фальшстарт и дальше все будет работать. Это самый дешевый вариант решения проблемы.

NeffЯ так понял кеширование средствами OC тут не причем? Не могу понять, почему так происходит.
Возможно ни при чем. Но надо сделать ситуацию повторяемой, чтобы все могли увидеть и подтвердить. Как понимаю как-то завязаны старт ОС и использование LIKE.

Свои данные мало кто готов предоставить для опытов, отчасти поэтому тут 21680375 выкладывал скрипт создания относительно большой БД со штрихкодами, можно на ее основе попытаться повторить данную проблему. Сегодня некогда, завтра позанимаюсь.

NeffДобавил индекс ко всем столбцам в своей базе через CREATE INDEX и все нормально заработало
Это бред какой-то и так точно не надо делать.
Индекс нужен для быстрого поиска, т.е. если ты пишешь


то тут нужен индекс по name, тогда поиск будет не перебором всей таблицы, а по индексу будут выбраны только нужные записи.
Минус индексов в том что при каждом insert/update требуется перестройка индекса, что тоже занимает время. Вкратце описал, не буду углубляться, при желании это в книгах почитаешь.
Явно дело не в индексах.

Несколько раз перечитал топик, согласен с подозрениями White Owl на антивирус, но сменой расширения его не проведешь. Просто отключи антивирус и запусти свою прогу - не будет тормозов, значит дело в нем, добавь прогу в исключения.

NeffDima T, да я почитал про индексы и с вами согласен, но то что без индексов первый запуск таблицы составляет 30 секунд, а с индексами 1 сек это факт. Как сделать по другому, что бы без индексов загружалось за те же 1 сек, я не знаю.
Индексы нужны, но там где надо. Как уже написал у них есть плюсы и минусы, т.е. прежде чем добавить индекс - надо понимать зачем он нужен.

NeffВ обще, ранее использовал под хранение данных, базы Access и там таких проблем не было, при том же формате таблиц и данных. Но затем пришлось искать альтернативу, так как у Access ограничение в 2 гб, а разделение таблиц на части делать не хочется.
Если у тебя база 2+ Гб и первый запрос делает скан всей базы, то считай: скорость чтения HDD ~100 мб/сек, т.е. 20+ сек в идеале. Скорость чтения памяти (кэша диска) 3-4 Гб/сек, т.е. меньше секунды. Скорее всего ответ в этом, сделай как я советовал 21723373 и забей.
NeffВот решил попробовать SQLite базы, но тут проблем оказалось не меньше, индексы, после удаления данных каждый раз вызывать команду VACUUM, что тоже не вариант, а PRAGMA auto_vacuum при создании таблиц не работает, так как видимо нужно включить параметр SQLITE_DEFAULT_AUTOVACUUM при компиляции библиотеки.
Ацессовские базы тоже пухнут и требуют сжатия, что по сути тот же VACUUM. auto_vacuum не рекомендую использовать, при твоих гигабайтах это будет тормоз после каждого удаления.
NeffЕсли подскажите варианты баз, для хранения больших объемов данных буду благодарен. Нужно что бы база хранилась на локальном диске, одним файлом и помимо текста, можно было сохранять в базе документы в формате Word и PDF. Знаю что хранить файлы в базе плохая идея, но так нужно.
Идея очень плохая, но если так нужно - хотя бы вынеси файлы в отдельную базу. Сделай одну нормальную базу, а вторую - куча файлов одной таблицей: (file_id int, file_data text) и там индекс по file_id чтобы быстро находить нужный файл.
По-хорошему надо использовать полноценный SQL-сервер (MSSQL, MySQL, Postgres, Oracle), но ты хочешь на файл-сервере прожить, тут только sqlite.