> полностью было бы хорошо проиндексировать урл, чтобы поиск вида
>
> ...WHERE url LIKE '%var%'
>
> использовал индекс.

Такой запрос никогда не будет использовать любой из изндексов типа b-tree(на
самом деле любой, построенный на упрорядочивании данных).

С частичным индексом индекс используется только при
> таком поиске:
>
>
> ...WHERE url LIKE 'var%'

Это твои домыслы. Будет такой запрос использовать индекс, если сервер
сочтёт его полезным для запроса, и это не будет зависеть от того, "частичный"
индекс или "полный". Поэтому кстати и делают префиксные индексы (по началу
ключа), потому что они ВСЁ РАВНО МОГУТ ИСПОЛЬЗОВАТЬСЯ, а эффективность
индекса с увеличением длины ключа снижается.

Главное, чтобы отрезанный префикс ключа был бы РАЗНЫЙ для разных ключей.

> UTF-8 в сязи с тем, что во втором текстовом поле упакована detail
> информация, которая в UTF-8.

Вообще-то разные поля таблицы могут быть в разных кодировках.
Особенно это верно для MySQL (т.е. для MySQL это ТОЧНО ВЕРНО, он
это умеет. MSSQL -- если только современный, ORACLE, PG -- не знаю)

Использование же master — details вставки
> сильно медленнее самой худшей вставки одной строки. Худшей — в том
> смысле, что максимальной длины индексы и utf-8 в "master" части.

Если тебе так нужны быстрые вставки, это ты значит что-то не так
делаешь. Быстрые вставки вообще не для СУБД, особенно транзакционных.
Единственная СУБД из обсуждаемых, имеющая опциональную ACID-транзакционность
-- это MySQL с движком MYISAM. Так что если тебе нужна скорость вставок,
то очень странно что ты с MySQL хочешь так расстаться: его все WEB-телепузики
именно за это и любят, за скорость (в ущерб транзакционности и надёжности)

> Каждый индекс разумеется замедляет вставку, но вот насколько — зависит
> от многих факторов.


На O( log(N) ) где N -- текущий размер таблицы. Особенно не от чего это
и не зависит.

По MySQL ничего определенного не подскажу, опыта
> нет. Кстати от длины ключа наверняка зависит.

Ну, зависит, но в тех случаях, когда индекс неэффективен и не нужен.
В случае нормальных индексов можно этим пренебречь.

> Нет, меня больше интересует подсказка, типа "oracle делает данные
> инсерты быстрее чем...".

Жёстко транзакционный Oracle делает вставки медленнее, чем MySQL + MyISAM.

> W>Очень вероятно поможет буферизация в приложении и вставка пачками по
> 100 и более строк.

Не поможет особо. Потому что это разница в несколько раз, а разницы между
транзакционной/нетранзакционной СУБД -- несколько порядков.