ну да. true и false примерно поровну. Индекс из одного поля, другие колонки в отборе не участвуют и индекс не содержит включенных полей для select"a примерно такого вида:
select field1, field2, ... where indexedfield = 0
И второй момент select count() с аналогичным отбором.
Откуда у меня такие сомнения? При отборе с результатом, скажем 50% строк, сервер сначала перебирает индексы для получения ПК, а потом ищет кластеризованный первичный индекс для получения остальных полей строки. Не дешевле ли сразу сканировать всю таблицу?
Я если честно немного не понимаю про что речь =))) Запрос (простой) может использовать только один индекс. В вашем случае если у вас 50% одно значение и 50% другое, то БД будет перебирать только пол таблицы, но это все еще очень дорого если таблица большая, если конечно у вас фильтр не по единственному этому полю, а то если поле одно то и перебирать он не будет. Скажем так, индекс отрезает от таблицы кусок по которому он будет делать поиск и чем больше этот кусок тем дольше будет поиск
не составной индекс булевый это типа одна колонка где 2 значения? Ну если в целом у вас там во всех строках одно значение то оно не даст буста
Это не совсем так, точнее это совсем не так =)) в каком бы порядке вы не составили индекс расположение в where полей индекса никак не влияет на его использование
Давайте тут уж по честному, если вы уперлись в производительность индексов (если мы подразумеваем что они используются корректно), то мне кажется тут пора писать своё хранилище, а весь проект уже давно на расте или си переписан =))
PS. И сколько смотрел докладов по хайлоаду, ни одна из топовых компаний не поднимала вопрос о том, в каком формате должен быть праймари кей и если с такой проблемой не столкнулись гиганты типа озона, авито и прочие ребята, то уж думаю местные владельцы проектов уж тем более в жизни не столкнутся чтоб задумываться об этом =))
Админка битрикса
Я прочитал по диагонали, но мне кажется там проблема в том что транзакции включают инсерты и конечно даже 5к транзакций в секунду это достаточно большая нагрузка на машинку в 8Гб и 4 ядра. Тут люди про сайты на DLE втирают что им ID числовой в урле даст какой то буст производительности =))
explain одного и второго запроса покажите. Во вторых вы тестируете на VDS я показывал на выделенном сервере, там может майнит крипту у вас кто
И еще важно чтобы поле было NOT NULL и желательно ключ уникальным
там в выборке всё равно участвует идентификатор, оптимизатор запросов mysql будет использовать его, сравнивайте ТОЛЬКО с выборкой по текстовому ключу
Нет там идентификатора эти числовые поля сами по себе не являются ключами их нельзя использовать отдельно, только все 3 поля вместе и среди 3х полей есть строка.
Четвертый скрин, там есть СТРОКА в выборке =))
Вы можете дальше жить в своем неведении и считать что ID в строке даст вам какой то значительный буст =))
Там если и будет разница, то фактически нивелироваться железом, вот табличка на 1.5kk записей
И в ней 3 индекса, 1 праймари и 2 составных (один чисто числовой, второй имеет строку) и собственно вот запросы
По праймари кею
По первому составному из 2х чисел
И из 2х чисел со строкой
В общем тут на уровне погрешности разница между ними и это вполне логично
у вас каша в голове, несмотря на то, что вы знаете, что такое b-tree, вы не знаете что такое целые числа, они не хранятся в виде строк!
Я вам задам другой вопрос, кто вам сказал что строки в индексе хранятся в виде строк? =))
Вы можете думать что угодно, я же вам предлагаю проверить.
