«горизонтальный» и «вертикальный» дизайн таблиц, SQL

Приношу извинения, если это было подробно рассмотрено в прошлом - я видел несколько связанных сообщений, но не нашел ничего, что меня удовлетворило бы в отношении этого конкретного сценария.

Я недавно просматривал относительно простую игру с примерно 10 тысячами игроков. В игре вы можете ловить и разводить питомцев, у которых есть определенные атрибуты (например, крылья, рога, гривы). В настоящее время в базе данных есть таблица, которая выглядит примерно так:

-------------------------------------------------------------------------------
| pet_id | wings1 | wings1_hex | wings2 | wings2_hex | horns1 | horns1_hex | ...
-------------------------------------------------------------------------------
|      1 |      1 |     ffffff |   NULL |       NULL |      2 |     000000 | ...
|      2 |   NULL |       NULL |   NULL |       NULL |   NULL |       NULL | ...
|      3 |      2 |     ff0000 |      1 |     ffffff |      3 |     00ff00 | ...
|      4 |   NULL |       NULL |   NULL |       NULL |      1 |     0000ff | ...
etc...

Таблица выглядит так и в настоящее время имеет более 100 столбцов, но в целом одно домашнее животное будет иметь только около 1-8 из этих атрибутов. Новый атрибут добавляется каждые 1-2 месяца, что требует добавления столбцов таблицы. Таблица редко обновляется и часто читается.

Я предлагал перейти к более вертикальной схеме проектирования для большей гибкости, поскольку мы хотим начать добавлять большие объемы атрибутов в будущем, например:

----------------------------------------------------------------
| pet_id | attribute_id | attribute_color | attribute_position |
----------------------------------------------------------------
|      1 |            1 |          ffffff |                  1 |  
|      1 |            3 |          000000 |                  2 |  
|      3 |            2 |          ffffff |                  1 |  
|      3 |            1 |          ff0000 |                  2 |  
|      3 |            3 |          00ff00 |                  3 |  
|      4 |            3 |          0000ff |                  1 | 
etc...

Старый разработчик высказал опасения, что это приведет к повышению производительности. проблемы, поскольку пользователи очень часто ищут домашних животных с определенными атрибутами (т.е. должны иметь эти атрибуты, иметь хотя бы один в этом цвете или положении, должно иметь> 30 атрибутов). В настоящее время поиск выполняется довольно быстро, поскольку не требуются JOINS, но введение вертикальной таблицы, по-видимому, означало бы дополнительное соединение для каждого просматриваемого атрибута, а также утроило бы количество строк или около того.

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

Я проводил тесты для множества случаев, но они в основном не дали результатов - время сильно различается для всех запросов, которые я выполнял (например, от полсекунды до 20+ секунд), поэтому я полагаю, что Вторая часть моего вопроса заключается в том, есть ли более надежный способ профилирования времени запросов, чем использование microtime (true) в PHP.

Спасибо.