Как переписать структуру таблиц или запросы, чтобы работал индекс для моих выборок?

Если уж иерархию доменов вводить - тогда можно просто subdomain вместо com.youtube.subdomain) А если еще и com.youtube разбить надвое, то можно отказаться от разворачивания наоборот

Станислав Макаров: Тут ещё просто момент, что если оставить com.youtube.subdomain, то можно будет легко искать так:
select id from domains where domain like "com.youtube%"

и соответственно:

select * from links
left join domains on domains.id =links.domainId
where domain like "com.youtube%"

Ваш вариант мне понятен, спасибо за участие. Но он влечет много дополнительных расходов, например:
1. при вставке новой ссылки, мы должны проверить не попадался ли нам ранее ее домен (субдомен), и если не попадался, мы должны определить в какой домен войдет текущий субдобен (например site1.co.uk и site2.co.uk - совершенно разные сайты, у них могут быть наборы своих субдоменов).
2. если в какой-то момент я захочу сайт economics.news.ru вынести как отдельный от news.ru сайт, то прийдется переписывать и связанные таблицы ссылок и доменов.
3. не понятно, что делать с сылками, для которых у нас еще нет соответствующих сайтов. Например при добавлении ссылки www.bbc.com/ukrainian/business у нас уже есть в базе сайт bbc.com и мы ассоциируем ссылку с ним. А если мы добавляем ссылку vasya2.site.org.ru/some/path, но у нас нет в базе ни сайта vasya2.site.org.ru ни site.org.ru. С каким доменом тогда ассоциировать это ссылку? С vasya2.site.org.ru или site.org.ru, а может org.ru? :)

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

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

sokolnikov:
> Я, конечно, понимаю, что тут два варианта, или мы тратим ресурсы при добавлении, но тогда нам проще с выборкой данных, или же мы меньше заморачиваемся с подготовкой данных при в несении, но нам придется тратить ресурсы при выборке. Но хочется найти золотую середину - решение, которые бы оказалось для меня самым удобным и практичным на больших нагрузках.

Это ключевое тут :)
чем больше нагрузка - тем меньше имеет смысл хранить данныве в данном как они приходят .

Как вариант - вы можете писать сначала во временную таблицу, и потом ночью обрабатывать её и раскладывать по полочкам.

Можете сделать так же так, что не использовать столбик main_id - можно и без него.
Т.е. ваш запрос будет выглядеть так:
select * from links
left join domains on domains.id =links.domainId
where domain like "com.youtube%"

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

Это всё решаемо.

Основной посыл:
переходите на цифровые индексы и не храните одни и теже данные в копиях.

Хорошо, спасибо за участие. Если через какое-то время не появится новое гениальное решение (на которое я очень надеюсь :) , иначе слишком много переписывать кода и слишком много данных переформатировать придется), то отмечу ваш вариант "решением".