Melkij

Посмотрите в explain, что планировщик думает по этим запросам. Есть большое подозрение, что хранимка и константный запрос идут по индексу по id, запрос с переменной - как-то иначе.

Одна очевидная грабля:
Значение переменной может изменяться во время выполнения запроса.
Константное значение в запросе и аргумент хранимки - не могут.
Соответственно моё предположение: глупый оптимизатор не смотрит, что в запросе переменная никак не изменяется, значит не может просто взять индекс по id и надо делать что-то другое. Скорей всего seq scan - судя по названию таблицы, данных подпадающих под условие dt <= дата куда больше, чем данных под него не попадающих. Для хорошей работы по индексу надо обратное свойство.

Объём - да.
Скорость - только линейная. Необходимость в большой линейной скорости - это исключение из правила, а не частая задача. Да и то на краю диска, к концу диска будет будет мегабайт 400 суммарных.
Тепла - всего-то 6 дисков. Один 3,5" диск - это примерно 6-10вт в рабочем режиме. 36-60вт энергопотребление, а это ещё и механика - здесь далеко не 99% энергии становится теплом, как у электроники. Тепла тут выделяется довольно мало.

raid0 - выход из строя любого диска = потеря данных всего массива.
Задача, для которой нужно много места, линейная скорость и при этом все эти данные нафиг не нужны и их можно в любой момент потерять... Обычно такое не встречается.

Никак. Поддержка этих возможностей была удалена в PHP 5.4.0

Вот синтаксис insert'а: www.postgresql.org/docs/9.4/static/sql-insert.html
Найдите тут where.

Что пытаетесь сделать?

С самой таблицей вы можете делать всё, что угодно? Например, заменить её на вьюху?
create view cur_time as select now();

Дата будет вычисляться непосредственно при обращении к вьюхе.
Только я не помню, как с вьюхами в mysql 4. Вроде должны быть.

Сделайте ограничение по IP. С возможностью указать несколько сетей. Просто, стандартно, привычно.
Для прозрачности - давайте подробный лог, мол по вашему ключу было столько-то таких-то запросов с такого IP-адреса. По идее градации день-IP-запрошенное действие-количество запросов будет достаточно чтобы и лог не раздувать сверх меры и давать подробную статистику пользователю. Если токенов может быть несколько - то дополнительно по токену счётчик
Не забудьте дать пользователю кнопку "ааа, срочно инвалидируйте мой токен!"

MyISAM

баланс на моем сайте

Сделайте мне это развидеть.

Это безотносительно проблемы. Хранить данные и нетранзакционное хранилище - взаимоисключающие вещи. Используйте единственное транзакционное хранилище в mysql - innodb. И добавьте внешние ключи.

Несколько маловероятно, что это непосредственная проблема, в штатном режиме даже myisam выборочно строки терять не должен так, что это заметил только конкретный пользователь. Более вероятна реакция mysql "аааа, таблица повреждена, я буду говорить только с админом". Впрочем, я давно уже не работал с myisam в продакшене, может и такое поведение тоже характерно.
А вот FK в режиме restrict вполне поможет от странных запросов.

select u.id, u.login
    coalesce(income.sum, 0) - coalesce(payment.sum, 0) as balance
    from users u
        left join (
            select user_id, sum(money) as sum from moneyuser group by user_id
        ) income ON u.id = income.user_id
        left join (
            select user_id, sum(money) as sum from payments group by user_id
        ) payment ON u.id = payment.user_id

left join и coalesce сделаны намеренно для корректного учёта пользователей, у кого ещё не было дохода либо выплат. Если нужно исключить пользователей, которые вообще ничего не делали, то допишите

where payment.user_id is null and income.user_id is null

было три HDD, на одном стоял xen server, на двух остальных хранилище.

Листинг pvdisplay прямо утверждает, что у вас было три террабайтных диска и на всех трёх были какие-то данные.
Затем, что вы потеряли 2 из 3 томов. При том в живых остался как раз том, на котором оставалось свободное место.

Уточняйте статус этих двух дисков.
Что можно в теории вытащить - запустите pvdisplay -m
Какие логические диски полностью укладываются в уцелевший физический - те сможете восстановить. Не полностью укладываются - соответственно в виртуальной машине будет сильно повреждён диск. Возможно, до неоперабельного состояния.

Как восстановить уцелевшее - гуглите. Я не пробовал. В теории (и мои поверхностные изыскания говорят, что да, так можно) инициализировать новые тома LVM со старыми UUID, затем восстановить конфигурацию LVM (она по дефолту бекапится в метаданных), тогда можно будет стартовать vg нормально и вычитать данные с нормального LV.

Я для похожей задачи пробросил целиком PCI устройство USB-хоста. Благо физические порты USB на плате относились к разным контроллерам: два независимых контроллера для USB2.0 и ещё один отдельный для USB3.0
Но нужна поддержка VT-d.

Смотря для чего именно.
Обработка одного запроса только однопоточная. Запросы по разным соединениям могут исполняться параллельно, т.е. утилизировать многоядерные CPU. Если не подерутся за блокировки между собой, конечно.

Обработка потока репликации - однопоточная до 5.7. Многопоточный слейв вообще-то запилили в 5.7, вот только он стал заметно медленнее в целом...
Я лучше сошлюсь на прошлогодний pgday и конкретно вот эту презентацию от mail.ru: pgday.ru/files/papers/2/pgday.2015.oleg.tsarev.pdf и запись доклада: https://www.youtube.com/watch?v=y8P-IWwzacY&index=...
Просто цитата оттуда для затравки: "Четыре потока 5.7 работают примерно как 5.5". В 5.5 реплика однопоточная.

Пропишите в конфиг. dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-...

И группировкой пользоваться всё так же можете. Но теперь группировка должна быть написана нормальным, стандартным способом, а не абы как, как ранее mysql позволял.