Здравствуйте. Есть база данных с большим количеством записей (сотни миллионов). Структура примерно такая: `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
`a` TINYINT UNSIGNED NOT NULL,
`b` TINYINT UNSIGNED NOT NULL,
`c` TINYINT UNSIGNED NOT NULL,
`d` TINYINT UNSIGNED NOT NULL,
`e` TINYINT UNSIGNED NOT NULL,
`f` TINYINT UNSIGNED NOT NULL,
PRIMARY KEY (`id`)
В настоящее время используется MySQL (MyISAM). От базы требуется быстро выполнять SELECT с произвольным количеством условий после WHERE. Проблема в том, что либо БД сканирует при таком запросе по всем записям, что очень медленно, либо требуется огромное количество индексов, что требует много времени на их создание и замедляет добавление новых записей. Как можно решить эту проблему?
Смотря что за where, какие поля часто используются, какие редко, какие значения.
В целом — бить на части 2 способами
1) На несколько таблиц по «строкам». К примеру на две — в одной a от 0 до 127, в другой от 128 до 256.
2) На несколько таблиц по «столбцам». К примеру ace и bdf и может быть даже acdf — в зависимости от того, поиск по каким полям идет чаще или в группах.
По сути это те же индексы, но поскольку Вы уменьшаете объем для raw поиска, производительность может повыситься.
Так же может иметь смысл сделать не 4 поля abcd, а скукожить их в одно поле int типа допустим, и навесить индекс на него (может оказаться лучше чем составной по abcd).
И наконец, если не слишком жалко памяти, даже при 100 миллионах записей, можно попытаться пихнуть таблицы в память:) Смотря насколько толстые строки.
>На несколько таблиц по «строкам». К примеру на две — в одной a от 0 до 127, в другой от 128 до 256
Хорошая идея.
>Так же может иметь смысл сделать не 4 поля abcd, а скукожить их в одно поле int
Проблема в том, что в таком случае придется делать побитовые операции, а индексы их не поддерживают.
оно хранит данные упорядоченно по первичному ключу. аналог IOT из Оракла или кластерного индекса MS SQL. В вашем случае не надо вторичные индексы делать
Простой
Простой
Простой
