Антон Корзунов

Одна команда - одна запись. Много команд (в цикле) - много записей.
Если записей реально очень много (десятки-сотни тысяч) - имеет смысл использовать "unbuffered query".

Даже если такой запрос будет выполнять 5 минут - это совершенно нормально для операции которая выполняется раз в день.
Улучшить ситуацию можно через хранимки или начать использовать https://php.net/manual/ru/mysqli.multi-query.php
С другой стороны у вас совершенно "упушен" момент про индексы, и условия в первом и втором запросе различаются.
Что можно сделать чтобы было "совсем хорошо"
1. Установить тип поля артикуля в char[точный размер]. Вообще "fixed" таблицы, где размер строки всегда можно заранее посчитать работают лучше.
2. Добавить UNIQUE индекс на артикуль. Он же уникальный?
3. Идем по "новым записям" и "INSERT INTO table(...)... ON DUPLICATE KEY UPDATE price=newprice. В общем инсертим строки, но если такая есть - обновляем.
3.1 Если новых строк нет вообще - делаем только апдейты
3.2 Если есть - заводим еще одно поле - "dirty". В начале ставим в 0, в инсертах и апдейтах ставим в 1. После окончания работы строк, которые не обновлялись" будет 0.
4. Можно еще вспомнить, что любые строковые индексы работают плохо, как бы вы их не спрашивали. Можно добавить еще одно поле crc=CRC32(article), которая переведет строку в число.
4.1 Итого UNIQUE вешается на два поля - crc(первое), article
4.2 В WHERE выражениях можно делать WHERE crc=CRC32(?) and article=? - это будет работать очень сильно быстрее и без коллизий.

А вообще можно особо и не париться, например обновлять данные "в лоб" на локальном компе, а потом переливать дампы.

Не забудьте про моменты загрузки данных с сервера на клиент - типа ObjectManager от Яндекс.Карт или другие варианты реализаций.

var pos = str.indexOf(' ');
if(pos>0) {
word = str.substr(0,pos);
}else{
word=str;
}

Замените Apache на php-fpm\nginx — сразу станет немного лучше.

Вы почти правы — нужен периодический flush на стороне сервера.
А как заставить сервер передавать ответы gzipнутыми кусочками?
Либо можно изменить content-type на такой который не будет ловиться апачем и не згипаться, либо просто попросить chunked вариант трансфера данных.

1. в интернете полно классов по работе с json в любой локале, но они в 1000 раз медленнее встроенной функции
2. никто не мешает пройтись по входным данным, найти все строки( или все нужные строки) и провести их через iconv
3. да, единственный супер стабильный вариант — utf-8 везде

Pascal — 10 лет
C++ — 10 лет
C — 3 года
Lua — год
Java — 3 года
Javascript — 3 года
PHP — 4 года

И уже второй год зарабатываю только на PHP

Также могу сказать что много языков знать ВРЕДНО.
Потому что «мастеринг» у них просто разный. И мне очень мешает когда я подходы из одного языка напрямую отображаю на другой.
Что-то типа использованить «смарти» на C++ или протопипного програминга из lua или js на большой Java

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

Я вот очень люблю объектно-ориентированные шаблоны.
Но они сносят моск другим програмерам. Поэтому я люблю их исключительно дома: )

Бывают случае когда ORM не справиться с запросом. Просто никак.
И бывают запросы когда и нативный ввод SQL тоже не справиться с запросом.
Проблемы бывают как технические, так и архитектурные или скоростные.

Но в любом случае — чем хитрее и оригинальнее обвязка над конечной БД — тем лучше.
Начиная от работы с базой в несколько конектов, заканчивая работой с несколькими базами, или таблицами партироваными на несколько серверов. Или даже прямым отображением на сфинкс.

Так что нарисуйте что вам нужно сейчас, дорисуйте туда столько же из головы, из того что теоритически может вдруг понадобиться потом.
Соберите в единую систему.
И под эту систему ищите инструмент.
Но совсем чистый SQL не используйте никогда — как минимум запросы через свою обертку. Как минимум возмонжость как либо легко менять(или находить в запросе) имена таблиц.

Заходим в убунте во внешний вид, переходим на раздел Шрифты.
Перед вами настройки сглаживания.
Они могут очень сильно изменить внешний вид шрифта и даже… его размер :)
Например полное-субпиксельное выдает шрифт ~ на 10% меньшего размера чем «без сглаживания

«спасибо что прочитали всю страницу» — отлично смотреться будет

Сам использовал вариант 2.
Как не странно — очень часто выбрать правильное — не так уж и просто.
Долго парился с группами и правильными ордерами, чтобы выбирать последние данные кучи разнородного материала.

Кончилось тем что историю храню отдельно, а последний срез данных — отдельно.
Вообще никаких проблем, да и операции с главной базой стали проще и быстрее

Учите Lua — ФП аля JS. Почти на 99% схожи эти языки. Ну кроме банального синтаксиса.
Или про него все забыли?

Использовать самопальный json::encode — там кода на 20 строк.
И даже кормить его cp1251 без конверта.
У таких решение только один минус — работают в сотни раз встроенного решения.