edogs

Почему бы не посмотреть как сделано в vbulletin, invision или просто какой-нибудь хорошей CMS? Задача авторизации это реально такой баянистый велосипед… заодно подсмотрите всякие интересные штуки типа индивидуальной соли паролей, логин с запоминанием или без, серверную авторизацию как опцию и http only печеньки и прочее и прочее.

1) В свежих мускулах лимит во вложенных работает вроде как.
2) Если мускул не свежий, можно делать выборку во временную таблицу, потом аппелировать к ней.
3) Честно говоря решение со вложенным запросом кажется утяжеленным в любом случае.
3) Задачу Вы ставите как «3 уникальных фамилии», однако в примере решения Сидоров=3, Петров=1, Иванов=2… а пример с вложенным селектом (n,n+3) подразумевает вообще не понятно что:) Вам надо «не больше 3»?
4)
select * from testid where surname in (
SELECT surname FROM `testid` WHERE 1
group by surname having count(subject)<=3
)
Во вложенном — выбираете все фамилии которые встречаются меньше 4 раз, и потом выбираете все данные с этими фамилиями.

habrahabr.ru/blogs/mysql/130905/ читать начиная с «Считаем количества прочитанных строк»

В my.cnf не прописано ли случаем socket=/var/lib/mysql/mysql.sock?

Если исходные данные позволяют, то load data infile может помочь.

Достаточно очевидно что надо повесить индекс на object_id.
Если у Вас type текстовый (иначе зачем лайк), то определенно есть смысл сменить его на enum, тогда и составной (type+object_id) может начать работать (только запрос надо будет переписать с лайка на in ('newad','renewad')

Старая проблема и старое прямое решение — вложенные запросы.
select * from p where
id_p in (select distinct(id_p) from pt andpt_val in (4447 ,4448))
and
id_p not in (select distinct(id_p) from pt andpt_val in (556, 535))
Лефт джоин для выдирания сразу и pt значений можно добавить по вкусу.
Но эта штука будет тяжелой… но без смены структуры по другому никак.

По поводу хетзнера и серверов. Обдумайте вариант взять www.hetzner.de/hosting/produkte_rootserver/ex5, конечно разоритесь на сетап, но 24Гб памяти вместо 8Гб решает в случае мускула достаточно сильно за счет кэша, особенно если у Вас много чтения.
Более того, иногда есть смысл повесить слэйв на сервер, где все таблицы находятся на ram диске. Для слейва рам не помеха, а вот для скорости чтение из оперативки это Вам не чтение с бытового винта, пусть даже на 7200.

Стандартное решение в том, что бы иметь тупо 2 разных коннекта.
Один идет на мастер, второй на слейв. Изменение на первый, чтение со второго.
Это самое естественное что может быть.

ну или www.linuxvirtualserver.org/, но это уже немного о другом.

Одно из самых простых — вешаем уникальный ключ принудительно, и сносим его.
ALTER IGNORE TABLE `backup` ADD UNIQUE ( `title`);
ALTER TABLE `backup` DROP KEY `title`;

1) Забацать таблицу id<->realid. Заполнять ее можно очень быстро посредством insert into select from. Соответственно в ней уже id не будут фрагментированы и будет очень легко выбрать.

2) Можно поступить аналогично п.1, сделав таблицу просто из realid, так же ее заполнив, и перемешать случайным образом. А случайное число выбирать позиционируя с помощью лимита, предварительно сгенерив случайное число на основе кол-ва записей.

Смотря что за where, какие поля часто используются, какие редко, какие значения.
В целом — бить на части 2 способами
1) На несколько таблиц по «строкам». К примеру на две — в одной a от 0 до 127, в другой от 128 до 256.
2) На несколько таблиц по «столбцам». К примеру ace и bdf и может быть даже acdf — в зависимости от того, поиск по каким полям идет чаще или в группах.
По сути это те же индексы, но поскольку Вы уменьшаете объем для raw поиска, производительность может повыситься.

Так же может иметь смысл сделать не 4 поля abcd, а скукожить их в одно поле int типа допустим, и навесить индекс на него (может оказаться лучше чем составной по abcd).

И наконец, если не слишком жалко памяти, даже при 100 миллионах записей, можно попытаться пихнуть таблицы в память:) Смотря насколько толстые строки.

Есть несколько извращенный способ для эстетов, суть которого сводится примерно к этому

select * from table as a 
left join table as b on a.added<b.added and a.category_id=b.category_id
left join table as c on b.added<c.added and b.category_id=c.category_id
where b.id is not null and c.id is null 

Вместо added можно использовать id, собственно так будет быстрее и суть скорее всего будет та же, но уж ключ на added должен быть обязательно.
При всей странности этого селекта, его скорость может удивлять по сравнению с другими способами, но только на небольших таблицах.
Самоочевидный смысл состоит в том, что бы вытянуть «по горизонтали» записи, а потом оставить только те, у которых нет последнего элемента, т.е. те, которые и будут последними.

---

При всем при этом, намного более правильным способом является введение доп. поля в таблице, в котором будет флаг, говорящий о том, что эта запись является одной из 2 последних. И обновлять это поле при обновлении данных в таблице.

Всё-таки если если «списковых» элементов относительно мало, то последний вариант имеет право на существование.

используйте полноформатную запись (CASE WHEN a.id > 500 THEN a.id ELSE a.id + 500 END) вместо new_column
альясы поддерживаются только в having выражении, в where их поддержки нет
на производительности это не скажется, при условии что полноформатку будете дублировать символ в символ включая рЕгИСтр.