За счёт того, что Salesforce хранит данные множества клиентов в единой базе данных, структура БД на сервере немного отличается от той, которую пользователь видит у себя в организации. Например, у стандартных объектов данные стандартных и кастомных полей хранятся в разных таблицах.
Полученный от организации SOQL запрос (или report фильтр, например) парсится и на его основе генерируется SQL запрос, уже исходя из структуры внутренней базы данных. Который, как следствие, может содержать в себе джойны, которых автор SOQL запроса вовсе не ожидал 
Помимо количества джойнов, на скорость работы запроса, очевидно, влияет количество возвращаемых записей.
Таким образом, если у нас есть некий запрос, который обращается к стандартным и кастомным полям какого-нибудь стандартного объекта, возвращает много записей и регулярно повторяется (обновление репорта, например), он может негативно повлиять (и обязательно это сделает) на производительность системы.
В такой ситуации целесообразно использовать Skinny tables. Это таблица, которая может содержать в себе поля одного объекта и копию данных, хранимых в этих полях. Более того, данные в skinny table синхронизируются с оригиналом, поэтому она всегда актуальна. Также, в отличии от обычного запроса, запрос к skinny tables не возвращает soft-deleted записи, просто потому что skinny tables их не содержит.
Обращение к skinny table уже не требует джойна, то есть мы избавились от самой затратной операции во всей этой истории. Если мы знаем, к каким полям данного объекта мы часто обращаемся “только для чтения”, то содержание ещё одной таблицы с копией данных - небольшая цена за существенное увеличение скорости работы запроса.
Но это же является причиной того, что skinny tables рекомендуется использовать только когда это действительно необходимо. Их использование в неправильном контексте может привести даже к уменьшению производительности. Именно поэтому создать skinny table может только Salesforce Customer Support по запросу от пользователя и после тщательной проверки, не испортит ли это ничего.
Наиболее удачный вариант использования данной фичи - объекты, содержащие миллионы записей и требующие повышения производительности read-only запросов (например, репорты или list views). Для такого случая, skinny table принесёт существенный прирост скорости выполнения запроса и, скорее всего, силу земли.
Skinny tables могут быть созданы для кастомных объектов и для стандартных Account, Contact, Opportunity, Lead, и Case.
Они поддерживают следующие типы полей:
- Checkbox
- Date
- Date and time
- Number
- Percent
- Phone
- Picklist (multi-select)
- Text
- Text area
- Text area (long)
- URL
На что ещё следует обратить внимание:
- Skinny tables могут содержать не более 100 полей.
- Skinny tables не могут содержать поля, принадлежащие другим объектам.
- Skinny tables копируются с прода на Full sandbox при рефреше. Для того, чтобы активировать их на других типах сандбоксов, необходимо обратиться к Salesforce Customer Support.