Здравствуйте. Есть 1 большая таблица, в которой сейчас записей 17млн. Будет 200 млн записей через пару дней, когда мы зальем остальную информацию. В дальнейшем в день таблица будет пополняться на 700к записей.

p1-p9 - это игрок в карты, который может сидеть на разном месте в раздаче за столом.
psd и pp - просто статы, как сыграл.
handLimit - лимит раздачи.

Нужно доставать информацию настолько быстро, на сколько это возможно. В таблице есть составной индекс p*_handLimit , чаще всего выборка будет работать именно по p* + handLimit , но если попытаться выбрать все записи с игроком, то запрос уже сейчас занимает 1.25с. Т.е. в будущем запрос может длиться и 5+ секунд.
Игрок записан в mediumint 3 байта.

Сам запрос:
авторSELECT `id`, `currency`, `pp1` AS `profit`, `psd1` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p1` = '9121'
UNION ALL (SELECT `id`, `currency`, `pp2` AS `profit`, `psd2` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p2` = '9121')
UNION ALL (SELECT `id`, `currency`, `pp3` AS `profit`, `psd3` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p3` = '9121')
UNION ALL (SELECT `id`, `currency`, `pp4` AS `profit`, `psd4` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p4` = '9121')
UNION ALL (SELECT `id`, `currency`, `pp5` AS `profit`, `psd5` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p5` = '9121')
UNION ALL (SELECT `id`, `currency`, `pp6` AS `profit`, `psd6` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p6` = '9121')
UNION ALL (SELECT `id`, `currency`, `pp7` AS `profit`, `psd7` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p7` = '9121')
UNION ALL (SELECT `id`, `currency`, `pp8` AS `profit`, `psd8` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p8` = '9121')
UNION ALL (SELECT `id`, `currency`, `pp9` AS `profit`, `psd9` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p9` = '9121')
ORDER BY `id` ASC
Использую юнион, Потому что обычный OR OR OR ... медленнее на 30%. Движок MyISAM , важен только селект и инсерт.
Апдейтов никогда не будет, а заноситься значения будут раз в день 1 минуту по времени.
my.cnf настроен не знаю как, пару лет назад что-то там пытался, таким он и остался.
Серверная машина - 128гб оперы, 16 потоков 8 ядер.
И соответственно EXPLAIN запроса и стуктуру таблицы приложил в изображениях:

Упс, это старая таблица. Прошу прощения. Вот новая

miksoftВообще таблица просится на "разворот" в вертикаль и на отделение результатов игроков в отдельную таблицу. Тогда всех этих UNION ALL-ов будет не нужно. И индекс будет нужен один вместо девяти.
Честно? Я не представляю как это реализовать :( Пытаюсь, но пока не получается.

miksoft8POWER-,

Помимо предыдущего замечания:
Вы уверены, что нужно использовать именно float? 4 байта как-никак...
Смотрите, я вчера думал о том, чтобы урезать handLimit с флоат до smaillint , итого экономлю 2 байта * строки.
Возможно так и поступлю, а умножать на 100 буду в пхп.

Но, профит как использовать не флоат? Если допустим писать в центах вместо 1.01 , понимаю, но если игрок выиграл 150000$ , это я не преувеличил, действительно в день есть больше 50 выигрышей от 80к+$. То тогда не влезет запись и все равно придется 4 байта уже отдавать(

miksoft8POWER-Но, профит как использовать не флоат? Если допустим писать в центах вместо 1.01 , понимаю, но если игрок выиграл 150000$ , это я не преувеличил, действительно в день есть больше 50 выигрышей от 80к+$. То тогда не влезет запись и все равно придется 4 байта уже отдавать(Даже в этом случае float плохой выбор, если не хотите потом удивляться, почему у вас 0.1+0.1=0.19999..., а не 0.2.
Для денег лучше использовать либо более приспособленные типы, например, DECIMAL, либо целочисленные в нужном масштабе.
Для масштаба 0.01 ... 150000 хватит типа MEDIUMINT, правда, без запаса. INT - с запасом.
Да судя по mysql.com, mediumint хватит в Maximum Unsigned value , а это не вредно? Я обычно по Maximum Value ориентировался. сейчас посмотрю какие максимальные выигрыши были за 17млн.
Про 0.1 + 0.1 - уже удивлялись, поэтому округляли и качали bmath для php , mysql - javascript #2 :D

miksoft
отдельно этот фрагмент за какое время выполняется?

SELECT SQL_NO_CACHE `id`, `currency`, `pp1` AS `profit`, `psd1` AS `isSD`, `handLimit` FROM `ps_hands` WHERE `p1` = '9121' Total execution time in seconds: 0.11549305915833

Если в кеше запрос - то 0.02

miksoft8POWER-,

И еще - план показывает оценку порядка 300 тысяч записей в результате (сумма колонки rows). Вам точно нужны все эти записи? Да еще в отсортированном виде?

Да, нужно получать все данные, если пользователь указал фильтр за всё время, сортировка так же нужна для построения графика.

miksoft8POWER-Да судя по mysql.com, mediumint хватит в Maximum Unsigned value , а это не вредно?Не понял, что именно может быть вредно? Либо вам хватает диапазона и точности, либо нет.
Диапазоны целочисленных типов .

Не подходит unsigned, так как профит игрока может быть отрицательным.

miksoft8POWER-пропущено...


Да, нужно получать все данные, если пользователь указал фильтр за всё время, сортировка так же нужна для построения графика.С этим надо что-то делать. Никакой пользователь не будет читать сотни тысяч записей и никакой экран не покажет график из сотен тысяч точек.
Либо отказывать пользователю в таком запросе, либо показывать предагрегированные данные, либо что-то еще.

Мы не отдаём пользователю все точки, однако нам они нужны чтобы подсчитать каждую и вывести ему график со всеми результатами.
Данные разделяются на 1 тысячу точек, а при приближении любой части графика - рендерятся новые точки.
К тому же пользователь запрашивает даже не 300тыс. записей, а может и 2млн запросить, если у оппонента наиграно столько рук и ему нужна статистика за все время.. А в 90% случаях нужна.

miksoft8POWER-,
Показанный запрос - единственный тип запросов, которые будут выполняться или есть и другие?
Только такой тип.

miksoft8POWER-пропущено...

Только такой тип.Тогда я бы попробовал разделить таблицу на две, как писал выше - 21687504 .
И, возможно, перейти на InnoDB. Он может быть быстрее при выборке по первичному ключу.
Но, конечно, нужно делать тесты.
Хорошо, спасибо