ThunderCat

Смотреть документацию по JOIN, читать про "отношения один ко многим" или, в зависимости от логики приложения, "отношения многие ко многим". Должно помочь.

для начала стоит посмотреть какого типа колонка `source`.`new.remains.costsum`, ее формат должен совпадать с форматом `target`.`remains_costsum` - double(15,5). В противном случае, если колонки не совпадают по типу, колонки не совпадают и по размеру и очевидно в `source`.`new.remains.costsum` содержится превышающее заданный диапазон значение.

делаю запрос в бд, вытаскиваю товары которые есть в API и пытаюсь искать в массиве вытащенных товаров - товары, которых нет в API через in_array,

Для этого есть not in, перечисляете айдишники/уникальные идентификаторы всех пришедших с апи товаров, и у оставшихся ставите наличие 0 одним апдейтом.

но что-то фигня какая-то получается, находит один единственный товар, который есть и в API и в бд

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

Как уже написал Akina, полной совместимости между этими версиями нет, но основной синтаксис без каких-то хитропопых движух по типу хранимок и кастомных/новомодных типов полей вполне совместим.
Что можно попробовать:
1) Добавить в начале дампа игнор внешних ключей, судя по всему у вас в транзакции происходит фигня, но что конкретно ее вызывает не видно, возможно таблица требует ссылки на внешний ключ, который еще отсутствует. В конце стоит снова включить контроль ключей. DISABLE KEYS и SET FOREIGN_KEY_CHECKS=0; в начале, и соответственно включить в конце дампа.
2) Если база большая, а инсерты в дампе не разбиты по строкам на адекватные блоки, можно попробовать убрать транзакции и посмотреть что конкретно не нравится системе. Возможно надо разбить инсерты на более мелкие блоки вставки, а возможно есть действительно несовместимый синтаксис.
3) Если такие танцы не помогают - костыли с методом описанным Akina, через csv и потом ручками связи/ключи/индексы/хранимки.

UPD: Народ говорит что может помочь принудительное указание типа движка таблиц и предварительная конвертация:

The tables must be InnoDB. After converting the tables to InnoDB, the database could be migrated

В основном, видимо, нагружают они.

Профилирование?

Есть ли какие-нибудь хорошие файловые хранилище с которыми удобно и практично работать?

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

Владею: Html, Css, Php, bd msql, сложные запросы SQL

Рили???

Ок, на самом деле решение очевидное, и весьма простое. Во втором запросе вы выбираете не столбец, имя которого будет ассоциироваться с ключом в соответствующем массиве (о чем вам и говорит ошибка), а результат агрегирующей функции, которое в массиве будет иметь совершенно другое имя. Что легко проверяется через var_dump($row).

Решение - добавить алиас для агрегированного поля.

выводите свой запрос в строчку:

$sql .= " LIMIT " . (int)$data['start'] . "," . (int)$data['limit'];
var_dump($sql); exit;
$query = $this->db->query($sql);

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

В цикле делать explode по разделителю, если полученный массив имеет длину более 1 - вложенный цикл, перебираете полученный массив, если длина = 1 то просто берете само значение.

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

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

group by + count()
или
count(distinct())

$count_m = "82;Тут очевидно синтаксическая ошибка сразу. Молчу про то, что числа намеренно передаются строками...

if($this->page==1) {
	$page = 1;
}
else {
	$page = (int) $this->page;
}

Это что за магия? Что оно вообще делает? Что будет если единица ВНЕЗАПНО попадет в блок else??

$start = ceil($count_m/$m_per_page);А теперь подумайте, как должна называться переменная, считающая общее количество страниц.

суть в том, что когда формируется limit 72, 24, т.е 3 страница,

Стоит пройти курс арифметики за 2 класс, и посчитать что 3 страница будет limit 48, 24.
limit 24, 24 - вторая и limit 0, 24 - первая.

1) Да, при условии наличия индексов помимо примари кей.
2) Примерно то же самое - при наличии внешних ключей в эти таблицы запись будет идти медленнее с ростом количества записей и соответственно перестройки индексов.
3) См. п. 2.

1) сделайте нормальные имена полям, что за rid, rname, ryavka, тут с большой буквы, там с маленькой... кроме того что половина полей транслитерацией кривой, так еще и префикс зачем то присобачили... С переменными та же фигня.
2) База должна соответствовать 3 нормальной форме, соответственно 2 значения в поле вашей рявки быть не должно, это должны быть 2 отдельных поля (или вообще внешняя таблица, если там много значений предполагается).
3) Соответственно в запросе нужно будет дать дополнительное условие по наличию второго поля, тогда ответ будет такой как надо.
4) В вашем случае предполагаю что ответ вообще не приходит, или приходит пустой, так как при запросе из пустого результата в первой же итерации цикла все упадет как раз с описанной ошибкой.

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

ini_set('display_errors',1);
error_reporting(E_ALL);
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

что позволяет вам (пострчно):
1) отображать ошибки и предупреждения
2) отлавливать ошибки и предупреждения
3) выдавать ошибки запроса в бд через ошибки пхп

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

Понял что это связанно с htmlspecialchars, но как победить его так и не понял.

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

Во вторых - научитесь отладке. Если вы не знаете в чем вообще проблема, стоит посмотреть что и на каком этапе пошло не так, для этого в самом примитивном виде нужно использовать var_dump/print_r, ну или инструменты по типу xdebug.

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