ПРИСОЕДИНИТЕСЬ к запросам по сравнению с несколькими запросами
Я столкнулся с этим только сегодня. Так хорошо, стандартного способа нет, но ...
Поскольку ОП просто необходимо увеличить выходной диапазон и перецентрировать его на 0, (от -1 до 1, а не от 0 до 1), почему бы просто не удвоить его и вычесть 1?
Я использовал это:
(x < 0) * 2-1
Или, принудительно сдвигая бит:
(x < 0) < < 1 -1
Но компилятор, вероятно, все равно оптимизирует это.
6 ответов
Это слишком расплывчато, чтобы дать вам ответ, относящийся к вашему конкретному случаю. Это зависит от многих вещей. Джефф Этвуд (основатель этого сайта) на самом деле писал об этом . Однако по большей части, если у вас есть правильные индексы и вы правильно выполняете JOIN, обычно будет быстрее выполнить 1 поездку, чем несколько.
Да, один запрос с использованием JOINS будет быстрее. Хотя, не зная взаимосвязей таблиц, которые вы запрашиваете, размера вашего набора данных или расположения первичных ключей, почти невозможно сказать, насколько быстрее.
Почему бы не протестировать оба сценария, тогда вы будете знать конечно ...
В зависимости от сложности базы данных по сравнению со сложностью разработчика, может быть проще выполнить множество вызовов SELECT.
Попробуйте выполнить статистику базы данных как для JOIN, так и для нескольких SELECTS. Посмотрите, работает ли JOIN в вашей среде быстрее / медленнее, чем SELECT.
Опять же, если изменение его на JOIN означало бы дополнительный день / неделю / месяц работы разработчика, я бы придерживался нескольких SELECT
Ура,
BLT
Создавайте как отдельные запросы, так и объединения, затем измеряйте время каждого из них - ничто не помогает, кроме реальных чисел.
А еще лучше - добавьте «EXPLAIN» в начало каждого из них. запрос. Это сообщит вам, сколько подзапросов MySQL использует для ответа на ваш запрос данных и сколько строк сканируется для каждого запроса.
Будет ли он быстрее с точки зрения пропускной способности? Вероятно. Но он также потенциально блокирует больше объектов базы данных за раз (в зависимости от вашей базы данных и вашей схемы) и тем самым снижает параллелизм. По моему опыту, людей часто вводит в заблуждение аргумент «меньшее количество обращений к базе данных», когда на самом деле в большинстве OLTP-систем, где база данных находится в той же локальной сети, реальным узким местом редко является сеть.
Я действительно пришел к этому вопросу в поисках ответа, и после прочтения данных ответов я могу только согласиться с тем, что лучший способ сравнить производительность запросов к БД - это получить реальные числа, потому что там просто для многих переменных, которые следует учитывать, НО, я также думаю, что сравнение чисел между ними почти во всех случаях не приводит к хорошему результату. Я имею в виду, что числа всегда следует сравнивать с приемлемым числом, а не сравнивать друг с другом.
Я могу понять, если один способ запроса занимает 0,02 секунды, а другой - 20 секунд, это огромная разница. Но что, если один способ запроса занимает 0,0000000002 секунды, а другой - 0,0000002 секунды? В обоих случаях один способ в 1000 раз быстрее, чем другой, но действительно ли он все еще «колоссален» во втором случае?
Итог, как я лично это вижу: если он работает хорошо , выберите простое решение.