UJey

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

Недоброжелатели это врятли, да и санкций тоже никаких не будет если сайт не совсем новый, единственный выход смириться )

попробуйте группировать так: GROUP BY MD5(url)
и избавитесь от limit'а, например так:
where id > 20 and id < 30
пример выше подходит только для сплошных id (т.е. что бы не было разрывов/пропусков)

Я думал над этим. Оказалось довольно сложно.
В таблице большой объем данных. Добавляются новые записи каждые 20 минут. Получается, что каждые 20 минут нам нужно для каждой новой записи пробежать по всему массиву данных и понять — была уже такая новость или нет. Если была — берем ее ID и записываем «для этой новости есть еще и другой раздел».
Я правильно понял идею? Хранить только уникальные новости, а дублирование выносим в промежуточную таблицу. Проблема в ресурсоемком вычислении «дубликатов». Сравнение-то по url (строка переменной длины).

Тут вы ошибаетесь в нескольких моментах:
70 000 статей это не большой объем данных, это очень маленький объем данных. Большой это на 4-5 порядков больше.
Каждые 20 минут сделать SELECT `id` FROM `news` WHERE `url` = $url это менее затратная операция чем для каждого посетителя делать GROUP BY `url`
Строка переменнйо длины — если длина ограничена можно сделать поле varchar и по нему индекс и все будет нормально работать.

без GROUP BY данный запрос выполняется 0.7 сек

а по полю active индекс сделали?

Кстати EXPLAIN, что по вашему запросу выдаёт? Может базу подтюнинговать, ибо 70 000 это же мелочи.

почему не сделать связь многие-ко-многим между таблицами news и sections?
тогда группировка будет не нужна.