Иван Мельников, я не вижу подробного описания логики происходящего. Только желание зачем-то избавиться от агрегатной функции в её оконном представлении, на практике совершенно бессмысленное.
Или вопрос носит чисто академический характер и не имеет реального практического воплощения?
если хадкорно прописывать, то соответственно они вставляются в конец таблицы.
В таблице в принципе нет понятий "начало/конец/перед/после/выше/ниже/раньше/позже/прочее". Таблица - это куча. Несортированная куча.
Если нужен некий порядок записей - то он обеспечивается в получающем записи запросе с помощью соответствующего выражения в ORDER BY.
Если ORDER BY не задан - записи возвращаются в произвольном порядке. И в двух последовательных получениях этот порядок имеет полное право различаться. Если же задано ORDER BY, но его выражение не обеспечивает уникальности записей, то указанная возможность получения произвольного порядка распространяется на каждую отдельную группу, для которой значение выражения сортировки одинаково.
Что же касается последовательной нумерации в группе - она выполняется программно. Например, триггером на основании дополнительной опорной таблицы.
Если переопределение скорости выполнять так же часто, как мигает светодиод на индикацию трафика, связи не было бы вообще. Autonegotiation требует в среднем около секунды (ну то есть само по себе оно быстрее, но пока пойдут байты, секунда, а то и две, проходит).
Вот в неправильную разводку или некритичный пробой - верю.
Ну сообщение об ошибке же совершенно явно говорит - при попытке подключиться клиент (PHP) не говорит серверу (MySQL), что тот должен запросить пароль учётной записи.
Это то же самое, что и разница между mysql.exe --user=root и mysql.exe --user=root --password
phpmyadmin с пользователем root и пустым паролем не подключается.
Это PHP не подключается.
Проверяйте настройки подключения. Может, MySQL работает только через сокет, а PHP пытается подключаться по IP? или ещё какие несоответствия? файрвол опять же...
PS. Сообщая о проблеме, следует цитировать полученные сообщения об ошибках. Причём полностью, и в неизменном виде.
несколько чатов быть не может, в данном контексте чат = лс
Нынешняя структура таблицы никак не препятствует наличию таких дубликатов. Потому несколько чатов может быть. Возможно, как следствие сбоя либо ошибки, даже если клиентская логика типа против. И возможность наличия/существования таких дублей даже не обсуждается.
Задавая вопрос о производительности, следует как минимум выложить полные CREATE TABLE для всех участвующих в запросе таблиц, а также дать статистику данных в разрезе отбора/связывания/группировки.
И я не понимаю, почему в вопросе упомянуты перенос и INSERT, но показан запрос на выборку. Описывать надо весь процесс.
Ну и 20 минут на вставку 2кк записей - это что-то дофига.
Или вопрос носит чисто академический характер и не имеет реального практического воплощения?