Melkij

Потому что btree умеет обрабатывать не только равенство, но и запросы на диапазоны данных.
Как именно на уровне кусочков данных - изучайте структуру b-tree и других деревьев поиска.

Сомневаюсь, что у вас GPT. Скорей всего классический MBR.
Соответственно, 5 раздел создать вы банально не сможете. Нужно удалять четвёртый раздел, на его месте создавать extended раздел, поверх него уже логический для /home и другие нужные логические.
Затем, есть огромное сомнение, что винды научились загружаться с логических разделов. Более вероятно, что только с основных.
Соответственно, переразбивать диск надо будет капитально.

Ну, решение без переустановки системы всё равно есть. Только муторно бывает иногда.

Если вам-таки повезло, и диск с GPT таблицей разделов, то создать 5 раздел не проблема. А вот вопрос загрузки виндов с GPT таблицы разделов оставлю вам на самостоятельную проработку. Там какие-то идиотские ограничения есть, что и при каких условиях делать можно, а что нет.

Посмотрите в 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 вполне поможет от странных запросов.