Как отсортировать данные SQL запросом?

Iskander48, добавьте поле сортировки и в нем укажите нужный порядок. Если писать нужную вам логику сортировки прямо в запросе выглядеть будет ужасно.

Как в php типизировать переменную самым коротким способом?

michaelromanov90, код должен быть понятный, для этого он не обязательно должен быть очень коротким. Введение дополнительной переменной вполне может помочь в понимание, что вы взяли из большого массива и зачем, если дать ей хорошее имя.
Дмитрий,

Возможно просто не стоит приводить к числам, а проверки делать не строгие, либо просто правую часть кастить к строке, это в разы сократит строки кода.

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

SQL инъекция в UPDATE возможна ли?

FanatPHP, ну как зачем, после prepare в памяти сервера постоянно будет висеть подготовленное выражение, соответственно должен быть способ его убрать. Хотя лимит на их кол-во большой, что-то около 16 тысяч, но на практике при уничтожении объекта prepared statements идет запрос deallocate prepare на сервер. Даже если его не уничтожать, он будет уничтожен при уничтожении объекта соединения, и все равно перед закрытием соединения полетят deallocate prepare.
У меня подготовленные выполняются на 12% медленнее эмулированных (без переиспользования), для MySQL 5.7 и MySQL 8, причем в 8 все запросы работают медленней. Интересно то, что в PostgreSQL разницы нет, подготовленные выполняются также быстро, не смотря на необходимость большего кол-ва запросов по сети. Также интересно то, что PDO по-умолчанию выбирает эмуляцию для MySQL, и подготовленные для PostgreSQL. Проверял на php, не думаю что есть разница, но надо бы попробовать в другом языке.

SQL инъекция в UPDATE возможна ли?

FanatPHP, совсем никаких изменений? Даже если смотреть чисто документацию, в 8 исчезли ограничения кеширования prepared statements, связанные с тем, что бинарный протокол смотрел только запросы бинарного протокола, не обращая внимания на текстовой.

Ну а насчет матчасти - вот и займись ей. Бери wireshark, смотри сколько там "сетевых запросов" будет
Впрочем, можно просто подумать, а нафига там три-то? :)

Так возьми wireshark, открой документацию, ознакомься с теорий и сам ответь на вопрос зачем 3 запроса: prepare, execute, deallocate prepare.

SQL инъекция в UPDATE возможна ли?

FanatPHP, подучил матчасть.
Вопрос с китайскими кодировками похоже уже поправили, но в любом случае экранирование не гарантирует 100% безопасности. Насчет эмуляции действительно неверно написал, тут вопрос не к MySQL, а к PDO использующему эмуляцию по-дефолту. Насчет производительности спорить не буду, вопрос неоднозначный.
А насчет этого:

откуда там три-то? Это риторический вопрос. На знание матчасти, а не фантазий системы "что вижу про то и пою"

учи матчасть.

SQL инъекция в UPDATE возможна ли?

FanatPHP, ну так научи, а не просто "что вижу про то и пою".

Как сократить время выполнения SQL запроса?

Soho,

в этом поле может быть vin код авто

Вы же пишите, что у вас таблица EAV, а то от такого комментария можно тронуться.

С учетом ваших вычислений, вероятно стоит рассмотреть вариант вынесения в отдельную таблицу, где использовать integer. Т.к. нужно еще и среднее, то индексация не поможет, все равно придется проходить по всем 10 000 значений. Если возможно еще большее увеличение, то вариант не подходит.
И как уже предложили, вариант с уже рассчитанными агрегатами.

SQL инъекция в UPDATE возможна ли?

xukapy, улучшение производительности путем prepared statements действительно очень сомнительно. Построение плана достаточно быстрое действие по сравнению с остальными, выигрыш на этом ничтожен. А если мы говорим про MySQL, то там кеширование плана происходит только в рамках текущей сессии, т.е. если речь не про демоны поддерживающие постоянное подключение, то смысла нет совсем, ProxySQL, насколько знаю, тоже не сильно хорошо работает с ними. До последних версий 8ки MySQL (многие до сих пор используют 5.7, считая 8ку "сырой") не имел нормальной поддержки prepared statements, только эмуляцию, вероятно именно это причина возможности sql-инъекций при использовании prepared statements для китайских кодировок. Кроме этого, каждый такой запрос требует 3 сетевых запроса, что негативно влияет на производительность.
Т.е. используя prepared statements вы получаете наилучшую сейчас защиту от инъекций, если не используете китайские кодировки в MySQL, с незаметной для обычных проектов потерей производительности (а в последних версиях и вовсе незначительной).

В mysql для быстрого поиска по дате лучше использовать timestamp как int или как date (datetime)?

FanatPHP, это все верно, когда мы говорим о небольших данных. Если у нас достаточно большая таблица с соответствующими индексами, то памяти под все индексы никак не хватит. В принципе, этого и не нужно, т.к. в памяти хранятся только те страницы индекса к которым идет активное обращение. Т.е. возвращаясь к вопросу в обычной ситуации разницы нет никакой. Но, если взять описанную ситуацию, и мы формируем запрос требующий полный скан индекса, то за ранее неиспользуемыми страницами понадобится лезть на диск.
Представить себе запрос вида select * from order by на многомилионной таблице трудно, но даже если подобное потребуется такое стоит решать иными механизмами.

Ошбика базы данных mariadb.service No space left on device?

Денис Юрьев, например, в Арче. А в большинстве или нет - вопрос спорный.

Как слить 2 локальные ветки?

CenterJoin, не пишите что считаете нужно сделать, пишите что хотите получить. Что значит "запулиться еще из нескольких веток"?
В master нужно класть готовый результат, а не промежуточные состояния. Если у вас все закоммичено, то нет проблем переключиться на другую ветку и затянуть ее актуальное состояние.

Почему при выборке из БД учитываются даты с другим месяцем?

WeStlik,

неудобно мне так

почему? судя по тому что задаете здесь вопрос, вам неудобно так, как вы делаете.

Храните даты в формате даты, это избавит вас от множества подобных проблем. Либо приводите строки к датам и потом сравниваете, например с помощью str_to_date.

Каким образом поступить?

Северное Сияние,

из этого трясущугося всего боящегося красноглазика муж как из г. лопата.

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

Как взаимодействовать с базой данных расположенной на сервере из десктопного приложения?

Владимир Коротенко, да, пока вся работа представляет собой забрать данные из таблички для одного пользователя. Не проще ли тогда базу положить рядом с клиентским приложением?..
Если "безопасность тут 10 дело", то тогда вариант с API не ужасен, раз мы исходим из архитектурного подхода "и так сойдет..."

Как правильно синхронизировать 2 поля с разных таблиц?

Почему нельзя нормализовать базу?

Как проверить значение строки?

Талян, ENUM отличное решение, а BOOL зачем?

Как проверить значение строки?

ENUM отличное решение, а BOOLEAN зачем?

Как взаимодействовать с базой данных расположенной на сервере из десктопного приложения?

Владимир Коротенко, как не факт, когда автор указал, что СУБД на сервере. Создание запроса вещь быстрая и она будет в любом случае, формируешь запрос к СУБД или запрос к API. Создание соединения с СУБД тоже далеко не 160мс, но здесь да, будут некоторые потери, если ничего особого не делать.
Лучше заранее разделить такие вещи, чтобы можно было независимо управлять и разрабатывать серверную и клиентскую часть. Не факт, что в будущем клиенту нужно будет отдавать сырые данные из БД, и потребуется обработка на сервере. Плюс возможность масштабирования. Не говоря уже о том, что ходить напрямую в БД - это проблема в безопасности и ее придется решать ограничением доступа на стороне БД.

Как ускорить работу скрипта?

Я более чем уверен что этот скрипт максимально медленный

Что значит уверен? Проверьте и определите наиболее медленные части.

Как минимум, запросы file_get_contents можно делать асинхронно, если это допустимо.
Инсерты в базу, если их много делать по одному очень долго, отправляйте пачкой, по 10-50 штук в одном запросе.

Как взаимодействовать с базой данных расположенной на сервере из десктопного приложения?

Владимир Коротенко, так ведь СУБД тоже удаленная, лаг на запрос по сети будет одинаковый, к СУБД мы обращаемся или сервису там же.