March 2026

S M T W T F S
12 34567
891011121314
151617 18192021
22232425262728
293031    

Style Credit

Expand Cut Tags

No cut tags
Friday, December 31st, 2004 03:01 pm
SQLIte, однако, изрядно сосёт.



1. Каждая таблица в SQLite обязательно имеет целочисленный ключ, явный или неявный. Несмотря на это, счёт элементов таблицы не ведётся и select count(*) from table на таблице из, скажем, нескольких тысяч записей - весьма дорогая операция.

2. Запрос типа SELECT * FROM big_table JOIN small_table ON big_table.f1=small_table.f2 WHERE big_table.id IN (SELECT id FROM other_table WHERE condition LIMIT 5) - очень долгий. То же самое, только сначала вручную внутренний SELECT, а потом вписать ручками результат в IN - быстро. Какая оптимизация, где?

3. Но это мелочи ещё. Вот поинтереснее: запрос типа SELECT * FROM big_table JOIN small_table ON big_table big_table.f1=small_table.f2 - выполняется медленнее, чем SELECT * FROM small_table JOIN big_table ON big_table big_table.f1=small_table.f2. Типа хотите оптимизатор запросов? Так сами себе и пишите.

4. EXPLAIN у них - тонкое издевательство. Зачем он вообще нужен, если выдаёт пачку непонятного никому, кроме автора, ассемблерного кода? Неужто так трудно сделать explain как в MySQL, хотя бы?

5. При больших запросах память жрёт, как собака, явно больше, чем выделено под его кеш. Хотя, может, это я не понял, как его определение кеша устроено.

6. Работает с базой из 100 тысяч, скажем, записей и 6 таблиц весьма медленно - возможно, из-за 2-3, хотя из-за 4 даже выяснить это можно только экспериментальным путём.


Мне, конечно, скажут - за что заплатил, то и получил. Тоже верно. Но судя по их сайту, ожидалось гораздо лучшего.

Reply

This account has disabled anonymous posting.
(will be screened if not validated)
If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting