Есть баз данных. Таблица users. Есть регистрация. Каким наиболее быстрым и простым способом можно проверить наличие e-mail или username который ввели при регистрации, на наличие оного в базе данных?
Достаточно ли просто сделать выборку по введенному e-mail/username, посчитать кол-во полученных строк и если оно не равно 0, то завершать работу функции?
Сделать составной уникальный индекс по обоим полям. И далее простым запросом по этим двум полям. Не нужно даже делать их выборку, достаточно сделать обычный count
нет не будет.
В случае составного индекса mysql нужно только посчитать количество индексов которые в общем случае должны находится в памяти.
Выборка же может привести к дисковым операциям совершенно не нужным в этом случае
@demimurych Во-первых, это будет так, если будет задействован уникальный индекс по обоим полям и ничего больше.
Во-вторых, это действует только на таблицах MyISAM.
@demimurych dev.mysql.com/doc/refman/5.6/en/group-by-functions...
"mysql> SELECT COUNT(*) FROM student;
This optimization applies only to MyISAM tables only, because an exact row count is stored for this storage engine and can be accessed very quickly. For transactional storage engines such as InnoDB, storing an exact row count is more problematic because multiple transactions may be occurring, each of which may affect the count."
@VitaZheltyakov как я и говорил ты не понял описанного. В документации идет речь о том что в myisam запрос вида SELECT COUNT(*) FROM student; специальным образом оптимизированы для максимальной скорости выполнения. Именно такой запрос, без параметров с count звездочка.
Я же пишу совсем о другом. О том как работает сервер mysql с запросами и порядком их выполнения. Если запрос идет по полям которые являются индексами и выполняется count то выборка данных из таблиц не осуществляется а идет подсчет только по дереву индексов. В случае же когда идет не count а есть выборка поля даже если оно проиндексировано это может привести к дисковым операциям в случае если таблица не оказалась в кеше. Данные же индексов, сервер mysql старается держать в памяти всегда. Все еще конечно зависит от того помещаются ли эти индексы в обьем отведенной памяти, но даже если не помещаются это будет означать только то что, сначал будет дисковая операция на получение нужных индексов, а потом следом дисковая операция на получения данных.
@VitaZheltyakov Хранятся в месте, но это совсем не означает что вся база mysql лежит в памяти. При нехватке памяти дынные лежащие в памяти будут удалены, индексы же будут там храниться максимально долго.
@VitaZheltyakov Дружище. О своей компетенции вы уже заявили выше, не понимая азов. Не хотите внимательно читать документацию поступите проще,
Создайте базу данных InnodDB обьемом больше чем доступная вам RAM
создайте в ней уникальные поля и не уникальные.
Выполните несколько запросов и следите за дисковой активностью. Может тогда наступит просветление.
Ну или включите простую логику, какой смысл будет в индексах в InnodDB если любая операция приводящая к работе с индексами будет приводить к загрузке связанных с ними данными?
@demimurych Я уже Вам привел в доказательство официальную документацию. Так что теперь ваша очередь приводить доказательства.
По поводу логики я уже дал Вам ответ - Вы не понимаете разницу между MyISAM и InnoDB. InnoDB - транзакционный движок. Поэтому индексы и данные хранятся вместе. Индексы нужны, чтобы выбирать (просматривать) не все данные, а лишь часть.
@demimurych Настоятельно вам рекомендую не спорить с этим человеком, объяснить что-либо ему абсолютно невозможно. Понял это в подобной "перестрелке", после многократно натыкался на ответы данного юзера, большинство из которых были, мягко говоря, странные.
Вы подняли мне настроение.
Я привел ссылку на официальную документацию. А в ответ получил субъективное представление о работе СУБД и заверения в моей некомпетентности. Смех-смехом...
@another_dream Под ключами я подразумеваю индексы. Не стесняйтесь их вешать на поля, по которым часто будите производить поиск - потери времени работы практически нет, а скорость выборки возрастает много кратно (даже если индексы не уникальные)
