rPman

Информации мало, но проверьте внимательнее, возможно между запросом и ответом от базы данных стоит еще какой то код, может в нем ошибка?

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

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

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

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

p.s. индексы там и так используются, единственное, попробуйте вместо count(*) использовать count(индексируемое поле, используемое в where)

у LVM сильные просадки скорости записи при использовании снапшотов, каждый новый уменьшает скорость почти в два раза.

Нестабильный интернет бывает разным, но в общем случае решается прослойкой между клиентами и базой данных (обычное дело, да и ради повышения безопасности, в мир базу данных не открывают), время сейчас такое что наилучшее решение - http/https. В этом случае база данных может быть абсолютно любой, хоть текстовый лог хоть oracle.

При этом, если используется прослойка, вы можете организовывать репликацию и синхранизацию с несколькими вашими серверами самостоятельно, иногда это даже удобнее и проще чем городить штатную репликацию баз данных, особенно если интернет нестабильный. Т.е. при получении данных от устройств вы отправляете два/много запросов на ваши сервера (асинхронно само собой) и ждете отведенный таймаут (по которому отключаете сбойный сервер из списка и выдаете алерт) после чего отвечаете ок. При возврате в строй сервера, на него заливаются данные с рабочих (лог или поле со временем, если данные не удаляются).

Вложите логику формирования цены (ту часть что меняет ее часто) в базу, в виде коэффициентов, таким образом чтобы достаточно было изменять общие из них а те что хранятся у товаров были постоянными.

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

Отличным примером является хранение в базе цен в валюте той площадки, куда вы перенаправляете ваши покупки (не верю я что все 5 миллионов это ваше локальное производство, само собой вы перепродавец), тогда достаточно вычислять обменный курс используемых валют на вашу базовую и умножать ее при выводе.

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

Все зависит от того, где вы будете работать с базой, т.е. на каком языке и какими библиотеками будете пользоваться.
Универсальный случай - не доверяйте нецелым числам, в какой то момент вы можете получить очень неприятные округления!
Пользуйтесть целыми числами int64 (и самостоятельно делите на 10^8 при выводе и учитывайте если будете проводить умножения на такие же целочисленные значения , например при умножении на стоимость в другой валюте, которая будет храниться так же)

Если будете пользоваться php, пользуйтесь строковым представлением числа и методами BCMath - bcadd, bcdiv, bcdiv,..) таким образом даже на 32-битных системах (вам могут попасться такие виртуалки) вы не получите преобразование числа в float