- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день!
Есть таблица MySQL
Вопрос: как добиться наименьшего времени выполнения запросов типа
В таблице 10М строк.
Создать индексы для user_from и user_to
По-моему, никак. Любой запрос приводит к перебору всех строк. Разве что с индексацией помудрить, но тут я не советчик.
Скажу-ка крамольную, но рабочую идею У меня недавно стояла задача заливки контента в базу, при этом с проверкой на уникальность. Строк около 200К. Запустил скрипт, сижу, смотрю. Жёсткий тарахтит, одна строка в секунду добавляется... Посчитал, прикинул, подумал — ну нафиг. Снял задачу. Поставил RAM диск, перенёс папку data туда. Запустил, вот это другое дело. Около 6 строк в секунду, под конец тормозить стало, но за сутки управился. Потом слил дамп, перенёс всё на жёсткий. Усё.
Скажу-ка крамольную, но рабочую идею У меня недавно стояла задача заливки контента в базу, при этом с проверкой на уникальность.
Если строки небольшие были, то поставили бы на поле с текстом уникальный индекс. В другом случае, можно было бы создать дополнительное поле с хэшем текста. И уже на это поле индекс ставить.
n0name
Буду знать, спасибо.
n0name,
С индексами понятное дело.
Как лучше 2 индекса отдельно или составной, или вместе?
Я вот еще чего хотел узнать больше всего, первичный ключ нужен или нет в данной ситуации?
Ведь у InnoDB есть свойство проводить сортировку не по индексу, а по первичному ключу и индексу.
что имеете в виду под
или вместе?
в данном случае 2 индекса простых, составные не нужны, если поля задействуются в одном запросе, да и то нужно смотреть в зависимости от условий какой индекс будет.
n0name,
С индексами понятное дело.
Как лучше 2 индекса отдельно или составной, или вместе?
Я вот еще чего хотел узнать больше всего, первичный ключ нужен или нет в данной ситуации?
Ведь у InnoDB есть свойство проводить сортировку не по индексу, а по первичному ключу и индексу.
Для таких запросов, которые указали лучше на каждое поле по отдельному индексу. Первичный ключ тут лишний (опять же, если судить по указанным запросам).
ОК, понятно.
Всем огромное спасибо, а особенно n0name.
Оптимальнее всего такого рода запросы на агрегацию облегчать специальными полями, изменяющимися при добавлении или удалении первичных записей.
Добавили сообщение - изменили число сообщений к юзеру и юзера в основной таблице юзеров.
Конечно, при выборе способа нужно оценить соотношение обновлений и чтений этой информации.
netwind,
касаемо count-запросов могу сказать, что кешировать их буду немного по-другому