Большое кол-во записей в секунду в MySQL. Как читать последний порядковый номер столбца и добавлять к нему +1 при записи?

1. Скажем так. БД это не совсем моё, я в тему не углублялся, но где то\когда то читал либо коммент, либо статью, что добавление ключа даст буст скорости при выборке по полю. Т.е. если условно мне потребуется получить все записи sessid, то используя его как ключ - это будет быстрее. От этого и поставил ключом. Спасибо, буду вникать на досуге.
2. Тут всё немного сложнее, т.к. в дальнейшем, возможен вариант при которых через каждые X записей serialnumb, может всё таки начать встречаться одинаковый result для sessid. Я пока не приступал к этому вопросу, но понимаю что такая потребность может возникнуть. От этого в рамках вопроса, я написал то, от чего отталкиваюсь на данный момент) Сейчас просто реализую задачу от меньшего сопротивления.
3. Т.к. в данном случае я сам себе начальник, разработчик, наладчик, тестировщик и всё в одном - то в дальнейшем, для вывода данных, мне было бы проще использовать порядковую нумерацию в бд, чтобы облегчить себе работу при визуализации данных.
В любом случае спасибо что прочитали мой бред) Дельные советы, обязательно испробую.

Maksim Herasim, 1. Только если это единственное или первое поле индекса. Выборка только по второму (третьему и т.д.) полю не ускоряется.
2.

через каждые X записей serialnumb, может всё таки начать встречаться одинаковый result

Это должно решаться другими способами, записывать в SQL-базу, а потом искать по ней - не самое лучшее решение. IMHO, тут больше подойдёт InMemory NonSQL-база, которая будет хранить последние X записей для каждого sessid.
3. У каждой записи и так есть уникальный идентификатор id. Хотите красиваости на выводе - создавайте вьюшку, которая покажет порядковые номера. Незачем нагружать базу лишними операциями при записи.

Rsa97,
1. Воооот, спасибо за расширение кругозора, видимо когда читал - через слово запоминал. Могли бы поделиться в каком случае могло бы быть полезным использование несколько ключей?
2. Тут интересно, спасибо за наводку, про NoSql. Нужно будет вчитаться. Правда у меня опыта только с mysql на запросы хватает, а с mssql и postgre там только на уровне настройки сервера и бэкапирования знаю. Может знаете такие, чтобы команды попроще писать было? Или чтобы был софт на подобии navicat с query builder. Он мне в свое время помог разобраться с логикой построения запросов и немного с синтаксисом.
3. На счёт лишней операции, если я в одном запросе считываю sessid и в довесок получаю serialnumb. А в другой операции я заполняю поля sessid, serialnumb, result то сильно ли исключение result в select и insert упрощает жизнь базе? Специально замеры не проводил, но когда делал инсерт без serialnumb мне показалось что время +- одинаковое было, что на мой взгляд говорит о том, что оно не сильно влияет. Но опять же, не моя специализация и я не глубоко изучал вопрос. Благодарю за потраченное время!

Maksim Herasim,
1. Первичный ключ (PRIMARY KEY) - он вообще не про ускорение, а про однозначную идентификацию строки. То, что он ещё используется как индекс, это приятное дополнение. А по составным индексам всё просто. Индекс, составленный из нескольких колонок , ускоряет поиск в случае выборки по префиксу индекса. Например, для индекса (a, b, c) ускорятся запросы

WHERE a = ...
WHERE a = ... AND b = ... 
WHERE a = ... AND b = ... AND c = ...

и не ускорятся

WHERE b = ...
WHERE c = ...

2. Тут ничего конкретного не скажу, поскольку у меня highload'а нет.
3. Проблема не в самом serialnumb, а в том, как вы его получаете. Для избежания состояния гонки вам надо делать транзакцию и использовать блокировку таблицы на чтение, но тогда другие потоки будут ждать её освобождения. При этом поле serialnumb особого смысла не имеет.

1.Спасибо за разъяснения по пунктам! Тогда понятно, в моем случае такая выборка не будет производится, поэтому для меня это вреднее получается.
2. Понял, принял.
3. Но если по факту - если я не дергаю отдельными запросами resultid, а этот параметр идет в довесок к select - или когда я провожу запись insert, и в этом insert дополнительно к другим параметрам задаю resultid - сильно ли то влияет на производительность операции? Понятно что я могу это эмпирически выявить и проанализировать, но с Вашей точки зрения, дополнительная колонка при insert сильно ли усугубляет ?

Признаю честно, сначала я начал дорабатывать обработчик, с учетом замечаний с вашей стороны. Отказался от проверки уникальности result (на текущем этапе), отказался от заполнения serialnumb.... Но потом меня осенило и я кажется нашел решение. Мне известно что параметр sessid не возобновляется. Т.е. если этот параметр сменился на устройстве, то в дальнейшем он не будет возвращен, т.к. по сути это будет timestamp+uid кодированный в base64. А решение выглядит следующим образом. Хранение последнего serialnumb для каждой активной sessid в memory. Т.е. в рамках обработчика я буду хранить sessid+serialnumb в переменных и каждое поступление данных я буду смотреть, существует ли такой sessid из переменной а не бд, если существует, то при записи в базу буду читать эту переменную, делать ей +1, и записывать в бд. А если приходит sessid которого еще нет в memory, в этот момент я делаю проверку в БД (на всякий случай) и назначаю значение = 0. Если вдруг в БД будет такой sessid в таком случае я от туда беру последнее значение, и вношу его в переменную обработчика. Этот вариант я уже тоже проверил, у меня получилось что каждая переменная отжирает не более 5 кб, памяти. следовательно для хранения значений sessid:serialnumb для 1000 устройств будет отжор менее 5мб memory . Что меня более чем устраивает. В общем буду развивать пока оба решения, с serialnum и без него, когда подойду к визуализации данных, пойму на сколько это будет критично для меня, и уже приму окончательное решение. Спасибо за Ваш вклад в мой труд.