Сергей

Реализуется поиском по типу данных polygon

ну хранит-то на диске.
а вот после обращения к данным закэширует в памяти https://www.elastic.co/guide/en/elasticsearch/guid...
https://www.elastic.co/guide/en/elasticsearch/refe...

к слову, не забудьте про ограничение в 31Г на ноду.

Сделайте is_main NULLABLE и замените везде 0 на NULL. NULL-ы всегда уникальные, если можно так выразиться) Поэтому уникальный индекс по item_id + is_main будет ОК.

Быть очень просто: выпиливаем поле is_main, т.к. оно вносит избыточность, за которой надо следить (собственно, ваше условие, что только одна запись может иметь is_main, равное 1). Вместо этого впиливаем таблицу main_data (назовите как считаете верным), такой структуры: (item_id, id), поле item_id - первичный ключ, плюс вся пара является внешним ключом на my_table. Итого, у вас две таблицы одинаковой структуры (id, item_id). Однако в первой (которая my_table) у вас ключ (id), т.к. может быть несколько таких записей на один item_id, а во второй (main_data) у вас ключ (item_id). Во вторую таблицу вы сможете вставить максимум один элемент для заданного item_id (может правда такой записи не быть вообще, это придется контроллировать в коде). Кроме того, за счет предложенного внешнего ключа вы не вставите в main_data элемент, которого нет в my_table.

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

Или генерировать токен рандомно и хранить его в базе?

Именно.

У пользователя есть некий ключ, он им подписывает свои запросы.

Например ключ qwerty, в запросе передается user_id (например метод getUserNameById), тогда подпись - некая хеш-функция от параметров и ключа, например sha1($key . $methodName . $userId)

OAuth2.0 и обязательное использование защищённого соединения (SSL).

updateAll не поддерживает связи, сделайте через DAO и не заморачивайтесь

Зачем для этого регулярки?

$card = '4275245675672511';
echo substr_replace($card, '******', -10, 6);