Alex Wells

Нет.
Бандл - это логическая группа классов которая решает базовые задачи с обязательной возможностью переиспользования (начиная с Symfony 4 это деприкейтед подход), к примеру (обработка писем, провайдер для какого нибудь хранилища...)
Сервис - может быть так сформулирован как Вы написали, предназначен для решения локальных задач (работа с пользователем, управление заказом и т. д.) )
Репозиторий - это класс согласно соответствующему паттерну осуществляют взаимодействие с базой данных, достать или отправить данные из/в базу данных
Ентити - это что-то вроди маппера который обеспечивает взаимодействие между сервисами и репозиторием

Вот же

Конечно же здесь:
https://www.w3schools.com/html/html_intro.asp
И здесь:
https://developer.mozilla.org/ru/docs/Learn/Gettin...

И YouTube никто не отменял.
Есть канал, Traversy Media, так вот контент автора может заменить вам на долгое время сон, еду и воду, если у вас все в порядке с английским и вы решили идти в веб-дев.
Вот, в частности, видео по HTML
https://www.youtube.com/watch?v=UB1O30fR-EE
Контент годный абсолютно весь.

Как и написал Владимир Проскурин данные будут удалены из памяти, только если на этот объект больше нет ссылок. Это значит что в таком коде:

let arr = [ {obj1}, {obj2}, {obj3}, ... ];
let data = arr[2]

delete arr[2];

Объект всё равно останется в памяти, так как на него есть другая ссылка — "data"

Миллионы записей - это совершенно обычный и, я бы сказал, крайне небольшой кейс для MySQL.

Самое быстрое: отпрофилировать запросы (например, performance_schema=1 и подключить sys-таблицы, они наполнятся данными по прошествии времени), найти неоптимизированные индексами и добавить недостающие индексы на этих таблицах.

В порядке действий:

• анализ, что работает медленно (не "заказчик говорит медленно", а например "запрос для товаров, при выборке по акциям и покупателям" работает 2 секунды)
  
• оптимизация кода, работающего с запросами (снижение числа запросов или более точные выборки) -- самая популярная проблема,
  
  - снижал на этом только этапе в 1000-1500 раз,
  - видел по 1500 запросов на страницу,
  - видел 1 запрос, но на всю таблицу и потом по коду с этими данными гигантская работа, когда можно было сделать 2 ооочень шустрых запроса в БД с конечными данными :)
  - запросы в цикле, очень много раз видел (гуглить проблема N+1)
  
  
• оптимизация медленных запросов
  
  Сделать запрос более быстрым, за счет или более точных выборок, или более верного синтаксиса, или стоит например раздробить на нексколько очень мелких, а бекендом все привести к нужному виду
  
  
• индексы (сильно оптимизируют и бывают достаточны для решений многих бед со скоростью на большой выборке)
  
• кеш на стороне БД
  
• кеш на стороне приложения
  
• денормализация некоторых данных, например предагрегация (например меню сайта и нужно для каждого вывести число твоаров, каждый пункт связан с категорией, категорий много, чтобы каждый раз по 100 категорий на подсчет товаров для каждой не делать -- делать это сильно реже и хранить в некой агрегирующей табличке)
  

С техниками типа шардинга/репликации никогда не работал

Потому что save только сохраняет модель с уже установленными параметрами, перед ним нужно использовать fill, например.
https://github.com/illuminate/database/blob/master...
Единственный параметр это массив с настройками сохранения, а не поля модели.

В модели $fillable настроили? А ещё метод save() не может принимать вот так параметры, как вы делаете. Надо вызвать $model->fill($data)->save();.

https://laravel.com/docs/5.7/eloquent#inserting-an...

Насколько я понял вопрос, нужно установить по дефолту для param3 значение Null

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

Для этого есть Database: Seeding