ThunderCat

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

а полученный запрос после конструктора не смотрели? Иногда помогает - визуально оценить что наваяли если все мысли кончились )

Вообще вижу первый раз код на го, но мне кажется что здесь какая-то лажа.
Что нужно? понять были ли совпадения в базе? Так если в rows что-то попало(в смысле запрос не вернул пустое множество) то в базе есть совпадения, иначе пишем совпадений не найдено.

UPD:
В вашем случае больше подойдет так:

id := 123
    var username string
    err := db.QueryRow("SELECT username FROM users WHERE id=?", id).Scan(&username)
    switch {
    case err == sql.ErrNoRows:
            log.Printf("No user with that ID.")
    case err != nil:
            log.Fatal(err)
    default:
            fmt.Printf("Username is %s\n", username)
    }

Это из официального мануала.

Оох, такой каша вариться, моя не смотреть! (с) Jar Jar Binks.
1) Каша внатуре, ну да ладно, это пол беды.
2) Используйте prepared statements и PDO.
3) Формируйте запросы в переменные, только потом передавайте запрос на исполнение, так хоть можно дебаггить что там в запрос попадает.
4) Если нифига не ясно(как тут) - через строчку ставим print_r(), и так для всего что шевелится.
5) Profit

если только sftp то имхо никак. Если сервер снаружи имеет http - можно поставить phpmyadmin, при наличии там php. Или другой скрипт рулежки базой. Ибо sftp это протокол передачи файлов онли.

0) Использовать более современные методы работы с бд (PDO, prepared statments)
1) Убедиться что $_POST содержит нужные строки, для этого есть print_r() и vardump();
2) SQL строки сначала формируются в переменную, затем передаются на исполнение, т.о. их можно посмотреть до отправки в запрос, и понять где косяк, например вручную потом вставив запрос в какой-нибудь phpmyadmin.

это зависит. Если у вас 1 000 000 юзеров то будет чета дофига инсертов. А так - цикл, больше ничего собственно не придумаешь, выбираем все id(у вас же id в to вставляется?)
select id from users where 1
результат в цикле делаем инсертами, чотбы не повисло - памяти побольше выделить и время выполнения увеличить. Можно разбить на куски по 1000 и обернуть в транзакцию.

SET @i = 0;
WHILE  @i < 5 
SET @i = @i + 1;
select `name` from `tablename` where `name` = "Павел" 
END

Где, где б*дь вы находите этот код??? Дайте я сожгу эти сервера!!!!

Ну есть же нормальные ресурсы!

А куда должны попасть эти поля?
Как сказали в коментарии - завернуть в жсон обратно.
и глядя на код - вроде так нихрена не должно работать, у вас $a принимает значения строковые, а вы их потом как объект используете, или я не вижу большой отсутствующий кусок кода? Уберите форич, если данные всегда приходят в таком виде - проще захардкорить преобразование $json->dat->par = json_encode($json->dat->par). Я бы так не делал, но при том что вы используете деприкатед код - вам подойдет.

[offtop] * сОртировать [/offtop].
Вроде и буквами написано, а все равно как на китайском.
Сортировка в бд происходит не по значению, а по полю таблицы, вообще слабо понимаю что значит "отсортировать по этому значению". Объясните задачу четче, думаю сформулировав ЧЕТКИЕ требования к задаче вы или сами поймете что делать, или тут вам помочь смогут.

Нифига не понятно.

Первое и главное - ПОЧЕМУ НЕ PDO?Ну или MySQLi на худой конец. Ваш код - сплошное депрекатед.
Второе главное - почему не УТФ8??? Зачем эти [censored] полумеры?
как подключаетесь?
где токен соединения создается?
почему такие костыли - запросы в базу вместо конструктора соединения?

$sql = "SELECT * FROM `1otsev` WHERE `out_keys` IS NULL";

IS NULL затратная операция, замените все NULL на 0, станет работать быстрее гораздо.
запустите из пхпмайадмин 1 раз:

UPDATE  `1otsev` set `out_keys` = 0 WHERE `out_keys` IS NULL

а тут...

$sql = "SELECT * FROM `keys` WHERE `frase`='".mysql_real_escape_string($val)."'";

Пропустим момент того что код был впервые использован еще при царе Горохе, а благополучно забыт еще при Ельцине, относительно таблицы - индекс на frase есть? Вообще везде где вы делаете выборку - нужно индексы.
Вообще неплохо было бы замерить время которое уходит на запрос, а так же план каждого запроса посмотреть, уж очень страшно у вас получается, должно максимум пару минут отрабатывать.

при таких объемах надо смотреть в сторону хранимых процедур. Не дело таскать дохреллион данных между пхп и мускулем, в базу все равно как-то алгоритмично вносятся изменения? Так перенесите логику в бд. Это чисто для бд задача - перелопатить кучу данных из таблицы и внести изменения.

Я не совсем согласен с Максим Бабичев, такая практика ведет к ошибкам в масштабе приложения, + не тестируется, + никак не отвечает объектному подходу - какие запросы от жс к бд??? На клиенте я могу с вашими данными делать АБСОЛЮТНО что угодно, ведь предполагается что вопрос задан неспроста, вы действительно хотите передавать эти данные прямо к функциям запросов в бд? Аякс должен быть методом передачи данных от клиента к серверу(ну и обратно, но в данном случае не суть). Все манипуляции с данными должны быть отделены от запросов в бд как минимум 2 слоями абстракции - контроллером и моделью. В идеале еще и каким-либо абстрактным бд-движком - доктриной , самописным каким-нибудь, или еще чем. А тут у вас куча конкретных данных о структуре бд, полях, данных, что к какой таблице относится - кароче мохнатый лес. Смотрите реализации аякса в мвц.

1) В базу будет добавляться, тк условием для добавления является существование переменной $res, а она всегда у вас создается, что в нее записывается - другой вопрос.
2) поле id не выводится по причине того что вы его не выбираете, выборка происходит только поля ip, для всех полей используйте "*".

А зачем вам этот винигрет? Если уж так хочется извращаться - сделайте 3 запроса и сделайте array_merge

подземный стук detected!