Hint

Провел тестирование:
— таблица с 1 000 000 строк, движок innobd;
— Структура полей id, flag (TINYINT), time(timestamp), data(char);
— У поля flag два возможных значения;
— 10 строк имеют отличное от всех значение поля flag;
— Кэширование запросов отключено.

Итог:
— Индексы действительно помогают отсеивать результаты даже, если значений мало. У меня получалось без индексов среднее время 1,89 сек., а с индексами — 0,015 сек.
— Использование NULL в качестве одного из значений дало прирост скорости 0,005 сек. на миллион записей без индексов, с индексами прирос слишком мал.

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

Мне кажется будет эффективен следующий вариант (если не ошибаюсь, подобное решение в тасках симфони):
не использовать ни флаг ни время для выборки, а просто вторым, обрабатывающим сервисом «запоминать» последний успешно обработанный идентификатор, а выборку делать
where ID > @yourLastCalcedID

Это будет наиболее эффективно, естественно, если обработка сервисом протекает последовательно, линейно ID за ID, без пропусков и ветвлений между элементами обработки

Я бы для оптимизации этой таблички сделал разбивку на PARTITIONS
либо по датам,
CREATE TABLE demo (col1 INT, tasks VARCHAR(255), col3 DATE)
PARTITION BY KEY(col3)
PARTITIONS 4;
либо по полю обработки
PARTITION BY LIST (id) (
PARTITION r0 VALUES IN (0),
PARTITION r1 VALUES IN (1),

Индекс по 0/1 быстрый, поскольку нужные вам записи хранятся первыми же в HASH (а я искренне надеюсь, что вы сделали HASH индекс, а не BTREE)

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

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

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

Надо тестить, в общем…

Тут есть мнения с которыми я не совсем согласен. Давайте, разберем что такое индекс в упрощенной форме.

Если индекс на поле не установлен, то он проходит по всем записям и сравнивает, если флаг = 1, то выбрать запись. При миллионе записей будет миллион таких сравнений.

Если вы поставите индекс, то он сократит список до уникальных значений и он будет следующего вида:
0 — строки, где запись равна 0
1 — строки, где запись равна 1

То есть, сравнений будет всего 2.

Если вы объедините поля, то в индексе получится 999 900 уникальных временных значений и одно — 0, соответствующие 100 записям то есть будет 999 901 сравнение.

(если поле вообще уникальное, то выигрыш в том, что он остановит поиск после первого найденного элемента)

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

Насколько вообще существенно сравнение интежеров даже помноженное на миллион я не берусь судить, как и об увеличении обращений к жесткому диску. Но это будет однозначно дольше, вопрос только насколько, тут уже надо тестировать.

Другая ситуация с NULL. IS NULL — всегда будет работать без сравнения вообще. Тут я бы так и сделал.

Оно скоро навернется, 99% :)
Я недавно тоже выкинул отнюдь не дешевое кресло с металлической основой, крестовиной и т.д., то есть, казалось бы, не придерешься. Ан нет. И все начиналось точно так же, и до поры я с этим мирился, укреплял как-то, выравнивал. А потом седушка тупо отвалилась.

За деревьями не видим леса? :) GROUP BY не отменили же вроде.

SELECT p.* FROM p
LEFT JOIN pt ON p.id_p=pt.id_p
WHERE p.id_p=262 AND pt_val IN (4447, 4448)
GROUP BY p.id_p

Не насиловать мозг, заюзать explode()

давайте по пунктам.
1. В РНР нет строгой типизации. Это факт.
2. Из п. 1 следует, что типы будут приводиться автоматически в некоторых случаях.
3. Строка приводится к числу именно так: (int)«PHP»; // 0
(мне это кажется логичным)
4. Чтобы сравнить два разных типа, нужно один привести к другому. С этим тоже глупо спорить.
5. Вот тут, возможно, неочевидный момент — в РНР для этого строка приводится к числу. Это описано в документации.

Сначала придётся прогуляться по массиву и найти самый глубокий уровень. Это пригодится для rowspan.

Второй вариант, пожалуй, проще — смещение точек.

Положение верхнего правого угла исходного участка = x, y;
Положение верхнего правого угла перемещаемого участка = x1, y1;

Ну и если расстояние между точек меньше «процента погрешности», то верно.

Пример для вашего случая

ИМХО, проще нанять верстальщика. На фрилансе, например. Просто поделиться частью оплаты за проект.

для центрального блока в CSS
position:relative
для «наплывающего элемента»
.newlayer {position:absolute; left:Xpx; top:Ypx; z-index:999}
чем больше значение z-index тем выше элемент будет находится.
чтоб центрировать основной блок у него margin-left:auto и margin-right:auto
чтоб центрировать внутренний (плавающий) блок:
left:50%;
top:50%;
margin-left:-[1/2 ширины блока]px;
margin-top:-[1/2 высоты блока]px;

Сканеры штрих-кода (из тех, с которыми мне довелось работать) обычно работают в двух вариантах:
1) Эмуляция клавиатуры (те, кто подключаются через PS/2 или работают как USB HID)
2) Эмуляция COM-порта (те, которые соответственно втыкаются в компорт либо являются USB Serial Device)

Взаимодействие с первыми аналогично клавиатуре. В чем их плюс — возможность работы даже с тем софтом который не знает что такое «сканнер штрих-кода». Для программы это будет выглядеть полностью аналогично как если бы оператор набрал на клавиатуре артикул товара. (то есть полностью прозрачно для программ)
Соответственно, сериальные устройства для тех программ, которые знают что такое сканнер штрих-кода и умеют с ним работать.

Соответственно, вопрос. Вам для каких нужд? Если Вы хотите минимальными затратами организовать «рабочее место оператора» с взаимодействием через веб — то вариант с USB HID — это ваш вариант. Вы просто с помощью PHP рисуете форму, с полем, куда JS-ом выставляете фокус. Оператор «пикнув» сканнером штрихкода просто введет туда цифры. (И незабываем, какой еще ОГРОМНЫЙ плюс возникает, если штрихкод потерт и нечитается — оператор просто набивает артикул на клавиатуре в это поле.)

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

Это какая-то мерзенькая реклама. Я долго не мог одуплить, что происходит.

x264vfw страшен сам по себе и всячески порицаем разработчиками x264. Возьмите просто x264 c Avisynth (серию изображений загружать через ImageSource). Кодировать примерно так:
x264 --crf 18 --preset veryslow --tune film --output out.mp4 input.avs