я понимаю, что сделано, как образчик гавно кода, но может быть есть возможность не перепиливая все как то оживить?

итак, майскуль (v. 5.6), очень большая таблица(100-150 млн записей) в ней поле статус.
большая часть поля статус, естественно, уже чтото типа "архив". нужно быстро отбирать записи с начальными статусами. их очень мало, не более 10000 в один момент времени типа



одновременно отбирается еще по паре полей с неплохой селективностью
собственно что с этой таблицей сделать можно не перепиливая много кода?
1. секционирование? хотя бы по годам с отсечением архива?
2. какой то хитрый индекс? ну по типу индекса по функции оракла DECODE(status,'5','5','10','10'), когда для других значений статуса вернется null, а он не индексируется, что позволяет получить компактный индекс в котором есть ссылли только на нужные блоки?
3. как то закэшировать строки с нужными статусами?

подкиньте плиз свеnлую мысль :-)

да просто индексы, естественно, есть.

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

вопрос по какому полю... и алгоритму дробить


они и так ридонли (в смысле у простых смертных нет способа там поковыряться). хотя да сделано странно.

те в майскуле пи смене моего статуса запись сама передет в другую партицию? слабо верится. пойду мануал почитаю.


это никому ни даст никакого профита. эта вспомогательная база через которую небольшой шлюз в интернет устроен. все остальное (и действительно ценное) внутри сети и в других базах.
я вот пытаюсь выяснить вообще нужно ли это хранить с ветхозаветных времен. может просто удалять все старше года к едреной фене.

ее копия есть в недрах основоной системы. хотя и в несколько ином виде.

int2

это не "моё" творчество.
но майскуль (как и большинство баз) справляется. план не поменялся, индекс используется.

вот в виде скрина.
говорит использую составной индекс (я его сделал первым делом).

первым полем стоит ид клиента, селективность там не плохая.
на самом деле ощутимой разницы нет, составной индекс или просто по полю статус.

Почему не используется? используется поиск по двум полям (в данном случае), клиент и статус.
Просто в первом примере запроса я привел фрагмент.
Ранее был поиск только по одному статусу.потребовалось сделать сразу по двум. начались проблемы явные с производительностью.
вариант с union all с двумя значениями тоже не очень здорово.
вот и ищу какую нибудь хитрость, которая позволит дотянуть до глобальной переделки.
вчера вот разрешили хранить это не более трех лет. (сейчас там с 2014 года). попробуем так плюс может партиции сделаю на таблице.