CMS для потрала с нагрузкой

я когда делал скрипт комментов и заметил что по первичному ключу id, запрос выполнялся медленнее чем по индексу varchar в котором было толи число толи хеш какой то 8-10символов 😀

Основная проблема строковых и uuid индексов в их фрагментации (непоследовательности ) - статейка. Много раз попадались на глаза советы делать числовые PK, но не видел годных тестов по замерам производительности. То есть насколько именно это критично. В идеале для теста надо сделать несколько разных, но схожих по составу таблиц с последовательным int, рандомным int и рандомной строкой в качестве ПК. Ну и uuid до кучи - последовательный и непоследовательный. Для чистоты теста можно сохранить "эталонную" таблицу со всеми значениями во всех тестовых таблицах и последовательно выбрать все эти миллионы записей и замерить время. Потом можно кластеризировать (упорядочить) индексы замерить ещё раз. Может получиться нормальная статья на свой сайт или для хабра.

А что это за программа или вебморда на скринах?

Это битрикс админка, где можно выполнять SQL запросы.

Админка битрикса

Я прочитал по диагонали, но мне кажется там проблема в том что транзакции включают инсерты и конечно даже 5к транзакций в секунду это достаточно большая нагрузка на машинку в 8Гб и 4 ядра. Тут люди про сайты на DLE втирают что им ID числовой в урле даст какой то буст производительности =))

Ага. А вот тестов по селектам с имитацией рабочей нагрузки в поиске не видать.

И, еще имхо, коль скоро мы говорим за фактический хайлоад, надо смотреть (тестировать) не только производительность PK, а еще скорость неуникальных индексов для отбора и джойна а-ля category_id, которые априори идут вразброс.

Ищё и от сервера зависит mssql, postgres и mysql могут вести себя по разному.

Размер строк для хранения ключа не имеет никакого значения. Он влияет только на скорость выполнения хеш-функции.
Сами хеши строк всегда одного размера (иначе не удастся обращаться к ним по указателю). Размер этих хешей обычно больше числового, то есть в одной ноде можно поместить больше ключей.
Кроме того сравнение чисел более дешёвая операция чем сравнение строк.

По большому счёту это все преимущества числовых индексов.

То есть выиграли на работе хеш функции (1) , размере массива в ноде (2) , сравнении/сортировке(3). Много или мало? 99,(9)% пользователей этого форума разницы ни на одном проекте не заметят.

Нет, не надо. Тут идёт дискуссия касательно выборки из БД данных одной-единственной статьи.

Давайте тут уж по честному, если вы уперлись в производительность индексов (если мы подразумеваем что они используются корректно), то мне кажется тут пора писать своё хранилище, а весь проект уже давно на расте или си переписан =))

PS. И сколько смотрел докладов по хайлоаду, ни одна из топовых компаний не поднимала вопрос о том, в каком формате должен быть праймари кей и если с такой проблемой не столкнулись гиганты типа озона, авито и прочие ребята, то уж думаю местные владельцы проектов уж тем более в жизни не столкнутся чтоб задумываться об этом =)) 

s Ещё надо убедиться, что все демоны переведены с tcp- на unix- сокеты /s