Админка битрикса
Я прочитал по диагонали, но мне кажется там проблема в том что транзакции включают инсерты и конечно даже 5к транзакций в секунду это достаточно большая нагрузка на машинку в 8Гб и 4 ядра. Тут люди про сайты на DLE втирают что им ID числовой в урле даст какой то буст производительности =))
explain одного и второго запроса покажите. Во вторых вы тестируете на VDS я показывал на выделенном сервере, там может майнит крипту у вас кто
И еще важно чтобы поле было NOT NULL и желательно ключ уникальным
там в выборке всё равно участвует идентификатор, оптимизатор запросов mysql будет использовать его, сравнивайте ТОЛЬКО с выборкой по текстовому ключу
Нет там идентификатора эти числовые поля сами по себе не являются ключами их нельзя использовать отдельно, только все 3 поля вместе и среди 3х полей есть строка.
Четвертый скрин, там есть СТРОКА в выборке =))
Вы можете дальше жить в своем неведении и считать что ID в строке даст вам какой то значительный буст =))
Там если и будет разница, то фактически нивелироваться железом, вот табличка на 1.5kk записей
И в ней 3 индекса, 1 праймари и 2 составных (один чисто числовой, второй имеет строку) и собственно вот запросы
По праймари кею
По первому составному из 2х чисел
И из 2х чисел со строкой
В общем тут на уровне погрешности разница между ними и это вполне логично
у вас каша в голове, несмотря на то, что вы знаете, что такое b-tree, вы не знаете что такое целые числа, они не хранятся в виде строк!
Я вам задам другой вопрос, кто вам сказал что строки в индексе хранятся в виде строк? =))
Вы можете думать что угодно, я же вам предлагаю проверить.
Чем логичнее? =) То что знаков больше? Так по вашему ID 10000000 будет искаться дольше чем строка address
Ключи в БД не выглядят как их значения, то что вы видите цифру 1 ключ это не цифра 1 =))
Ну вы же наверняка в валдбериез и яндекс маркете архитектором работаете, ведь так? =)))
Я конечно не работаю там, но предполагаю, что используют это для такой штуки как шардинг. Так как базу данных сложно масштабировать горизонтально, то принимают решение, что например ID товаров с 1 до 1кк мы храним на сервере А, а с 1кк до 2кк на сервере Б, без ID в урле это действительно сложно делать. Вы если мне не верите, можете сделать табличку на 2 поля, число по праймари и varchar на пусть 100 символов с индексом желательно уникальным и запустить тест выборки по полям. Я это все к чему, я работаю на проектах подобных что вы озвучили, и мы, например, используем как ключи uuid, а не числа.
Вот вам пример такой таблицы, есть ключ праймари и ключ по url (строке), для БД это один и тот же тип индекса, поэтому я не очень понимаю что вы мне тут пытаетесь доказать, я даже не уверен что у вас есть понимание работы всего этого, сделать эксперимент же делов то полу часа, зато сформируете свое мнение основанное на опыте и практике, а не кто то где то сказал.
Я думаю можно начать от сюда https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started.html
