Что выбрать для первичного ключа в таблице под MySQL

Я не профи, но не вижу профита делать первичный ключ из 3-х полей. Можно набрость таблицу с тестовыми данными и погонять запросы с explain.

Я бы сделал просто индекс по полям месяц+год. (В постгресе ещ можно было бы partial index по последнему месяцу сделать, чтобы все летало).

Ставим postgres ииспользуем наследование таблиц

Иди в баню, ты достал уже со своим постгресом. После твоих не в тему коментариев меньше всего хочется постгреса.

В свою очередь тройной ключ накладывает свои расходы на быстродействие т.к. 1) увеличивается трафик
1) увеличивается трафик

WAT?

Возможно ван нужен не индекс, а партиционирование по значению поля, самое оно для таких ситуаций

https://habrahabr.ru/post/66151/

Ставим postgres ииспользуем наследование таблиц

Убер тоже сначала поставили postgres, потом поплевались и теперь мигрируют на MySQL.

Не повторяйте ошибок убера, у них хотя бы есть деньги их исправить, а у вас?

Я бы использовал стандартный инкрементный ключ + индекс на дату, но все сильно зависит от ваших запросов, одну и ту же выборку можно получить 100500 разными способами с индексами и без.

Поделюсь своим опытом, не утверждаю что вам тоже подойдет:

1) пара {месяц,год} была замена на номер месяца, начиная с января 2000. В обе стороны конвертируется легко, а поле одно

2) таблица была разделена на две части. В одной только текущий месяц, во второй весь архив. Секционирование для бедных.

После твоих не в тему коментариев меньше всего хочется постгреса.

Что-ж конкретно вы можете использовать mysql вместо базы данных, CVS вместо Git ну и так далее. Мужайтесь и не сворачивайте!

Убер тоже сначала поставили postgres, потом поплевались и теперь мигрируют на MySQL.

Смеялись всем офисом)))

Не повторяйте ошибок убера, у них хотя бы есть деньги их исправить, а у вас?

Так расскажите же скорее какие они допустили ошибки при выборе PostgresQL?

Мигрируют на самописную NoSQL СУБД на основе мускулопараши*

Кстати, ты уверен, что у ОПа нагрузки уровня убера?

Не повторяйте ошибок убера

Сразу используйте постгрес чтобы потом не ебаца с миграциями.

Щас предложу. Тут конечно набегут. Но я всеравно предложу. Смысл в этом есть.

Тебе надо копаться выборками за «текущий» месяц. Никто тебе не запрещает генерировать при вставке значение для автоинкрементного поля. И никто не запрещает делать его разреженным, с пропусками. Ну вот возьми и впили там BIGINT(20) UNSIGNED AUTOINCREMENT пусть сам все индексирует. А при вставке новой записи кроме реальных датэтайм или таймстамп генерируй значение автоинкр ключа вида yyyymmddhhmmssuu и няхай вставляет. Выборку будешь делать так: WHERE id BETWEEN yyyymm0000000000 AND yyyymm0000000000

Чем это лучше обычного индекса по месяцу+год?

Тем что в одном поле и сразу упорядочено искаропки, на самом низком уровне, а не надстройками. Но я осознаю что это все пованивает. И я так не делал, нужны тесты как минимум.

Это не будет быстрее. Максимум с такой же скоростью работать будет. Никакой это не самый низкий уровень, обычный индекс. А вот программно это лишний геморой.

Не программно, а «паттерново», т.к. лабаться будет на какойнить готовой CRUD/AR хренатени. Гемор только отсюда.

Ухты! Кассная штука.