Вопрос: Как понять есть ли нагрузка на БД?

Лучший ответ: Почему больше всего подписчиков всегда слетается на самые дурацкие вопросы? 
Которым место в мусорке, а не на главной Хабра.
Ну ведь как в прошлый раз же, весь текст - какие-то бессвязные эротические фантазии, не имеющие ничего общего ни с реальностью, ни друг с другом, ни - главное - с собственно вопросом, который был задан.

Так вот: я смотрю, что получил 1500 строк из базы за 0.0316 секунд. Это нормально?
Нет, это ненормально.
За исключением очень редких и специфических случаев, в РНР мы никогда не запрашиваем больше, чем пользователь может комфортно просмотреть. Ну как бы есть конечно комменты под статьями на хабре, и в отдельных случаях там бывает за тыщу. Но это очень редкий случай. И что-то мне подсказывает, что здесь совсем не он.

База растёт и строк к выводу станет больше.
 С КАКОГО, я стесняюсь спросить, перепугу, с ростом базы строк к выводу станет больше?
На тостере с каждым днем прибавляется сотня дебильных вопросов. 
Ты уверен что количество запрашиваемых из базы строк тоже растёт? А если подумать? А если прям вот хорошенько подумать?

Этот ход мысли напоминает старый еврейский анекдот, который рассказывал Джоэл Спольский в далёком 2001 году:
Маляр Шлёма подрядился красить пунктирные осевые линии на дорогах. В первый день он получил банку краски, поставил её на дорогу, и к концу дня покрасил 300 метров осевой линии. «Отлично! — сказал прораб. — Быстро работаешь!» и заплатил ему.
На следующий день Шлёма покрасил 150 метров. «Мда, это, конечно, не так здорово, как вчера, но приемлемо», — сказал прораб и снова заплатил ему.
Ещё через день Шлёма покрасил всего 30 метров. «Всего лишь 30! — заорал прораб. — Это никуда не годится! В первый день было в десять раз больше! В чём дело?»

«Ничего не могу поделать, — говорит Шлемиэль. — Каждый день я ухожу всё дальше и дальше от банки!»

Тебе не кажется что эта логика напоминает твоё "но с каждым днём в БД появляется всё больше и больше записей!"?

На что ориентироваться? На показатели загрузки процессора или время выполнения запроса или расход памяти?
На учебники. В которых разжевывают все эти бессмысленные страдания на первых страницах. И где учат решать реальные проблемы, а не метаться в страхе перед неведомым. 

И вопрос в догонку: если одним запросом я получаю 1500 строк и если в запросе я установлю select нужных мне столбиков - это усложняет запрос или нет? Ведь в первом случае я получаю информацию как есть, а во втором случае процессору надо время чтобы перебрать нужные столбики?!
Судя по количеству восклицательных знаков - это самый важный вопрос во всём этом и так целиком гениальном тексте. Процессор опасносте!!! Срочно надо спасать! 

Запрос выполняется три сотых секунды, дом рисуется 10, но вопрос почему-то "как узнать , не тормозит ли база?"
Ну ей-богу, снова как в анекдоте - "Где логика??! Где разум??".

Сейчас я кеширую результаты php на 60 минут, 
Вот это я понимаю. Сразу заходим с козырей. 
странно что на 60 минут, а не на 24 часа. или вообще сделать сайт статикой. тогда вообще всё летать будет. Или вообще перенести всю БД на клиента. Чего не сделаешь ради борьбы за миллисекунды.

Как понять есть ли нагрузка на БД?/
Посмотреть, есть ли нагрузка. 
Тормозит ли сайт, есть ли загрузка по процу и памяти, есть ли отказы в обслуживании, ошибки в логах.
Если ничего этого нет, то сидеть на попе ровно и ничего не трогать!

А вместо всяких "оптимизаций" типа кэширования на 60 минут запроса, который выполняется пару сотых секунды, или не на покупки бессмысленного диска, а на букварь про работе с БД. И прочитать там про нормализацию, индексы, базовые команды SQL,  пагинацию, в конце концов.

И тогда и твоя микроскопическая БД в 10 тыщ записей, и нормальная база с миллионами строк, будут работать одинаково быстро и эффективно.

Худший ответ: Замеры производи на синтетических тестах, написав максимально простое приложение, которое будет долбить ваш сервис запросами (например bash скрипт с использованием curl), собирай метрики типа нагрузка процессора, диска, при разных количествах одновременных запросов и т.п.

В конечном счете ориентироваться нужно на количество запросов, которые сможет обработать сервер, при условии одновременно исполняющихся запросов (в скриптах можешь делать тесты с разным их количеством, и сравнивай результат)

Чтобы понять, будет нагружать и что в запросе, используй EXPLAIN, на практике нагрузку создают не сами выводимые данные, а фильтрация по ним, но в случаях многоуровневых запросов, когда для получения данных нужно связывать по форенкеям с другими таблицами, нагрузка логично возрастет

Кеширование - дает хороший прирост в чтении данных но заставляет решать вопрос инвалидации кеша при записи, т.е. может замедлить ее. Если второе проблемой не является, то тогда смотри, что дешевле процессор или память (кешировать можно и на диске).

ssd диски безоговорочно быстрее hdd дисков, тем более если сравнивать одинаковые сегменты (серверный ssd с серверным sas)

p.s. 1500 записей у клиента, оно ему надо? тем более сразу в dom ему все выдавать? на практике мало какие люди способны потреблять сразу всю информацию с экрана, область зрения у большинства сужена, и больше десятка уже не видят, да и на экран все не влезет, можно подгружать по мере прокрутки.

Фильтрацию же данных можно проводить и на сервере

С другой стороны, если говорить о кешировании, данные ведь и у клиента можно держать, снимая нагрузку на сервер при повторяющихся запросах, так что еще вопрос где лучше фильтровать данные.