Являются ли математические функции в MySQL быстрее PHP?

Я некоторое время работал с MySQL, но я никогда не использовал поддерживаемые математические функции , такие как FLOOR() , SQRT() , CRC32() и т. Д.

Быстрее / лучше использовать эти функции в запросах, а не просто делать то же самое в наборе результатов с PHP?

EDIT : Я не думаю, что этот вопрос является дубликатом этого вопроса, поскольку мой вопрос касается математических функций, перечисленных на странице, с которой я связан, а не CONCAT() или NOW() или любой другой функции, как в этом вопросе. Пожалуйста, подумайте об этом перед тем, как пометить.

На это нет общего ответа. Вы, конечно, не должны уходить от своего пути делать математику в SQL вместо PHP; это действительно не так уж важно, если таковые имеются. Однако, если вы все равно выполняете SQL-запрос, и у вас есть выбор для выполнения операции в PHP, прежде чем отправлять его в MySQL или в самом запросе … это все равно не будет иметь большого значения. Часто существует логическая разница в том, когда и как часто выполняется операция, и где ее нужно выполнять, и где код для этого лучше всего сохранить для хорошей ремонтопригодности и повторного использования. Это должно быть ваше первое соображение, а не производительность.

В целом, вам нужно сделать какую-то действительно сложную математику для любого из них, чтобы иметь какое-либо значение. Некоторые простые математические операции тривиальны практически на любом языке и в среде. Если есть сомнения, сравните свой конкретный случай.

Это более эффективно для этого в PHP.

Быстрее зависит от задействованных машин, если вы говорите быстрее для одного пользователя. Если вы говорите быстрее, когда миллион пользователей попадает на сайт, то эффективнее делать эти вычисления на PHP.

Загрузка веб-сервера под управлением PHP очень легко распределяется по большому числу компьютеров. Эти машины могут работать параллельно, обрабатывать запросы от посетителей и получать необходимую информацию из базы данных. База данных, однако, непросто работать параллельно. Такие проблемы, как репликация или осколки, являются сложными и могут потребовать специального программного обеспечения и правильно организованных данных. Это дорогостоящие решения по сравнению с добавлением другой установки PHP в массив серверов.

Из-за этого значение цикла ЦП на машине базы данных гораздо более ценно, чем значение на веб-сервере. Поэтому вы должны выполнять эти математические функции на веб-сервере, где циклы ЦП дешевле и значительно легче распараллеливать.

MySQL быстрее работает в SQL-запросе. PHP быстрее в PHP-коде. Если вы хотите, чтобы SQL-запрос обнаруживал SQRT (), он должен быть определенно медленнее (если только не PHP), потому что парсер MySQL и сетевые накладные расходы.

Как deceze сказал, что, вероятно, не будет большой разницы в скорости между использованием математических функций в SQL и PHP. Если вы действительно волнуетесь, вы всегда должны оценивать оба ваших варианта использования.

Тем не менее, один из примеров, который приходит мне на ум, когда, вероятно, лучше использовать математические функции SQL, чем выполнять математические функции PHP: когда вам не нужно выполнять какие-либо дополнительные операции с результатами из БД. Если вы выполняете свои операции в MySQL, вам не нужно перебирать результаты в PHP.

Существует дополнительное соображение, чтобы думать и это масштабирование. У вас обычно есть один сервер MySQL (если у вас более одного, то вы, вероятно, уже знаете все это). Но у вас может быть много веб-серверов, подключающихся к одному и тому же серверу MySQL (например, при наличии балансировщика нагрузки).

В этом случае лучше переместить вычисления в PHP, чтобы загрузить MySQL. «Легче» добавлять больше веб-серверов, чем увеличить производительность MySQL. В теории вы можете добавить бесконечное количество веб-серверов, но объем памяти и скорость процессора / число. ядер на сервере MySQL конечен. Вы можете масштабировать MySQL по-другому, например, используя кластер MySQL или выполнять репликацию master-slave и чтение с ведомых устройств, но это всегда будет сложнее / сложнее.