Самая распространенная - покадровая.
Просто как в мультфильмах.

Форматы с поддержкой анимации - не нужны.
Так как если анимация связана с определенными действиями - он кадры должны сменяться не как попало, а по определенной логики.

Если же кадры должны просто сменяться подряд - вполне достаточно и зацикленного видео.

Но чаще всего используют просто один большой файл, в который вкраплены кадры.

MySQL с нормальной структурой и индексами.

но получил жестокие задержки при попытке собрать статистику о действиях одного игрока

Ваша структура должна учитывать такую возможность.
Или - учитывать, что часть ответов дается БД быстро (те что нужны сиюминутно же, быстро), а часть (второстепенные, не нужные часто) - медленно.

Если прям хотите очень быстро - см. Tarantool.
Он относится к классу СУБД, дающих ответ максимально быстро.
Если уж на нем у вас будет тормозить - пересматривайте свою архитектуру.

Когда то давным давно процессоры только манипулировали 4 битными регистрами
Потом 8 битными
Потом 16 битными
Потом 32 битными (кое где осталось, в частности на смартфонах большинство)
Сейчас 64 битными (на десктопах везде уже, на смартфонах только появляется)

Смысл в том, что числа, которые процессор может, к примеру, сложить - скольки-то там битные.

То есть если у тебя 16-битная операция, а тебе нужно сложить 100 000 + 12 000 - где первое число уже выходит за пределы 16 бит - то ты сможешь это сделать только частями, в 2 этапа, в 2 операции.
Сначала младшие разряды, а потом уже старшие.