Поля которые естественно упорядочины. Нужно ли их индексировать?
Но вот предположим что есть поле, которое является естественно упорядочиным (например поле с датойв формате TIMESTAMP), но сервер то о нем не знает и получается, что будет сканить все записи в таблице хотя уже после 100-ой записи вмысла в этом нет. И получается, что времени уходит больше.
И в итоге выходит, что и хотя записи в поле упорядочины, индекс к этому полю вещать приходится. Или есть такой то способ пометить поле как упорядоченное, но индексов для него не создавать? Типа пометка/команда, которая уведомила бы MySQL, что во в этом поле данные упорядочины по возрастанию и что при достижении нижней границы диапазона выборки дальше сканить таблицу уже не нужно?
В любом случае, дополнительная информация о расположении основной информации уже является "индексом". Посему лучше сделать это "официальным" образом.
Если в 7 запросах из 10 идет сравнение по полю, допустим, customerid (например что-нибудь вроде SELECT SUM(incoming_pay) FROM pays WHERE customerid=7) то на такое поле надо навесить индекс.
Если же поле используется сравнительно редко (например какие-нибудь дополнительные данные которые запрашиваются несколько раз в год), то поддержание индекса на таком поле будет убыточно с точки зрения производительности.
Если же выборка идет на основе поиска внутри содержимого (например текст или бинарные данные), то тут создание индекса может стоить слишком дорого (особенно если текста много для каждой записи и записей самих более миллиона). Тут уже нужны другие подходы...
Как конкретно будет идти поиск - зависит от реализации сервера. Прикладной программист начинает над ней задумываться, только для оптимизации под конкретный сервер, если правильно сформированный по правилам SQL запрос выполняется медленно.
О числах сервер тоже ничего "не знает", и поэтому индексы строит по алгоритму AVL-деревьев. Поищи, почитай, что это такое.
Мои подозрения об отсутствии у тебя понятий СУБД подтвердились, уж извини за прямоту.
Согласно теории и стандартам реляционных СУБД, данные в таблицах и выборках (запросах select) располагаются случайным образом до тех пор, пока не указано предложение order by (в большинстве серверов также и group by). Соответственно, ни о какой первоначальной упорядоченности речи быть не может. Алгоритмы, основанные на физической упорядоченности данных, не являются реляционными. Продвинутые сервера имеют также понятие таблиц, организованных по индексу, данные в которых логически упорядочены по первичному ключу. Реляционной модели это не противоречит, поскольку использует индекс.
Не нужно считать разработчиков СУБД полными кретинами. Даже программисты MySQL поняли, что одними свободными исходниками СУБД не сделаешь, и взялись за ум. Хотя, до полноценной СУБД им ещё далеко.
О чём это я? Короче, за более чем 30-летнюю историю существования реляционной модели её реализация была обкурена математиками вдоль и поперёк, и все алгоритмы давным-давно прописаны в учебниках по системному программированию. Решена в них и описанная тобой проблема.
Если хочешь понять теорию реляционных СУБД и оптимизацию запросов на логическом уровне, почитай соотвествующую литературу - все вопросы о "преждевременной оптимизации" (той, которая корень проблем) отпадут сами собой.
В плане правильной качественной реализации теорий MySQL совершенно не показатель. Поэтому, если нечто, описанное в теории, в данный момент не работает в MySQL - это проблема MySQL, но никак не теорий. Постепенно несуразности в MySQL устраняются - и то хлеб. Живите и радуйтесь, или переходите на лучшие СУБД.
Согласно теории и стандартам реляционных СУБД, данные в таблицах и выборках (запросах select) располагаются случайным образом до тех пор, пока не указано предложение order by (в большинстве серверов также и group by). Соответственно, ни о какой первоначальной упорядоченности речи быть не может.
Но в данном случае она есть. Ибо есть поле типа timestamp, что это, как не естественный ключ? И в данной задаче записи так же получаются упорядочиными, т.к. записываются в хронологическом порядке.
Живите и радуйтесь, или переходите на лучшие СУБД.
Да нет, я не думаю, что в ближайший месяцы у меня возникнет надобность в СУБД уровня Oracle. MySQL за глаза, тем более что у меня на хосте только он и есть.
В общем спасибо всем принявшим участи. Вывод сделал один, индексы в данном случае нужны :)
Если ты его описываешь как constraint - да. Ограничения типа primary key и unique реализуются через индекс - дополнительный индекс на эти поля создавать не надо (цивилизованный сервер и не позволит это сделать).
Повторяю ещё раз: порядок следования записей в таблице не определён.
В большинстве реализаций место под строки выделяется некими кусками - страницами, в каждую из которых вмещается несколько строк. При первоначальном заполнении таблицы записи идут последовательно (в отсутствие иных правил, о которых говорилось выше), но если в дело вмешивается удаление...