Ваше описание «таблицы» и «базы данных» является классическим признаком отсутствия нормализации.«Таблица» с 20 доступными для поиска столбцами не 3NF и, вероятно, даже не 1NF.Лучший совет - вернуться к первым принципам и нормализовать данные, что приведет к гораздо более узким таблицам, а также к меньшему количеству строк в таблице, но, конечно же, к нескольким таблицам.Однако результат также имеет меньше индексов, по таблице и в целом.
И гораздо более быстрая база данных.«Жирные» таблицы - это катастрофа для производительности на каждом уровне.
Разделы здесь не применяются, они не облегчат вашу проблему.
id PK - это дополнительный столбец и индекс , суррогат, замена (но не замена) реального первичного ключа.Если вы использовали методы реляционного моделирования, это может быть устранено, по крайней мере, до 19 доступных для поиска индексов.Любая серьезная работа за «столом» будет сосредоточена вокруг реального ПК, а не суррогата, например, как вы видели из ограничений на разделы.
Если вы хотите это обсудить, пожалуйста, опубликуйте свой DDLдля «таблицы» плюс все подключенные «таблицы».
Ответ на комментарии
Таблица лучше всего воспринимается как «электронная почта»но с большим количеством дополнительных полей (категория / отдел / приоритет / рабочий процесс / владелец), которые все должным образом нормализованы.Существует также ряд других переменных, в том числе довольно много временных отметок.
Это само определение плоского файла, в 0NF .Если вы не используете какое-то неписаное определение «нормализации», оно, по вашему собственному описанию, вообще не нормализовано .Это статья, с которой начинается до начала любой нормализации.
Нет сомнений, что индексы также будут широкими, чтобы быть полезными для запросов.
и вы, возможно, не понялитем не менее, в этом файле имеется большое дублирование данных и аномалии обновления (когда вы обновляете столбец в одной строке, вы должны обновить дублированное значение в других строках), что делает ваше приложение излишне сложным.
Необходимо понимать, что все поставщики реляционных СУБД пишут реляционные механизмы баз данных, оптимизированные для обработки реляционных баз данных.Это означает, что они оптимизированы для Нормализованных, а не Ненормализованных или Денормализованных структур.
Я не буду втягиваться в академические аргументы, и SO - это сайт вопросов и ответов, а не дискуссионный сайт.По запросу опубликуйте свой DDL для файла и всех подключенных файлов, и мы определенно можем (а) дать ему некоторую скорость и (б) избежать более 20 индексов (что является еще одним распространенным симптомом состояния).Это решит конкретную проблему реального мира, решит ее и позволит избежать дебатов.
Во-вторых, похоже, что вы перепутали роли.Это вы, с проблемой, выкладываете вопрос на SO, и именно я исправил сотни проблем с производительностью, отвечая.По определению, решение находится за пределами вашего домена, в противном случае вы бы его решили, и, таким образом, вы не разместили бы вопрос;так что это не работает, когда вы говорите мне, как решить вашу проблему.Это связывало бы меня с теми же ограничениями, что и у вас, и, таким образом, гарантировало, что я не устраню проблему.
Также из наших тестов, имея множество таблиц, к которым можно присоединиться.мы должны включить в предложение WHERE только замедление запроса.
На самом деле я настраиваю базы данных на жизнь, и у меня есть сотни тестов, которые демонстрируют, что объединение множества небольших таблиц происходит быстрее.Было бы интересно взглянуть на тест и возможности кодирования кодера, но это приведет к дебатам, поэтому давайте не будем этого делать;давайте придерживаться вопроса.Если вам нужны примеры (а) серьезного тестирования, которое (б) подтверждает то, что я сказал до того, как его оспаривают, вот только один пример , полностью задокументированный и проверенный, и соответствующий тест сСтойкие в мире Оракула.
Вас также может заинтересовать этот вопрос / ответ , который привел к тому же спору, к которому вы приближаетесь.
Объединения ничего не стоят. файлы , к которым вы присоединяетесь;и количество записей , соединенных с обеих сторон; полезность индексов, в этом и заключается стоимость.Если это другой ненормализованный файл (толстый, широкий, много необязательных столбцов), обязательно он будет медленным.
В любом случае, если вы действительно заинтересованы в устранении указанной проблемы, опубликуйте все свои DDL, и мы сможем сделать это быстрее для вас.Если все, что вам нужно, это ответ да / нет на разделы (и чтобы не решить причинную проблему), это тоже хорошо;у вас уже есть это.