Snake800

После слов

Дальнейшие измышления автора стали не интересны.

По существу топика, если есть желание и жажда экстрима, то можно потроллить. Например, сказать, дескать, удалить пока не можем, т.к. на Вас подали заявление в правоохранительные органы и сейчас ведётся расследование.

А вообще, не стоит заморачиваться с такими "странным" людьми, их много. Пусть просит прощения и сносите следы его жизнедеятельности.

Я, хоть и не имел ввиду классическую генерёнку, но свой слив в контексте обсуждаемого вопроса признаю)) Тем не менее, их копирайтеры часто пишут такой бред, что он мало чем отличается от gpt-текстов.

+1 за вебнэймс. За 20 лет работы с ними заметил только два серьёзных минуса: платная 2F авторизация, рублей 460 в год, и как-то раз выдали данные администратора по адвокатскому запросу (в моём случае обоснованному). Зато с ценами не чудят и правила на ходу не меняют.

ну да. true и false примерно поровну. Индекс из одного поля, другие колонки в отборе не участвуют и индекс не содержит включенных полей для select"a примерно такого вида:

select field1, field2, ... where indexedfield = 0

И второй момент select count() с аналогичным отбором.

Откуда у меня такие сомнения? При отборе с результатом, скажем 50% строк, сервер сначала перебирает индексы для получения ПК, а потом ищет кластеризованный первичный индекс для получения остальных полей строки. Не дешевле ли сразу сканировать всю таблицу?

Пока отцы не разошлись, земной вопрос: не составной индекс на булевых полях (male/female) - зло?

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

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

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

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

А вот интересно: если бы в CF задались целью фильтровать ПФ ботов - за сколько дней или недель они бы решили этот вопрос? 🤔

В-основном и так уже львиная доля приходится на авторитетный по мнению ПС крупняк типа КП, АиФ, журнал Тинькофф и т.п., которым можно всё. Но доры их всё равно теснят с завидной периодичность.

Дропнутые домены госорганов в большинстве своём seo-ценности не имеют. А так обычно картина примерно такая: 1300 доноров, ИКС 500, дроп планируется 12 числа - ставка уже 120000₽.