オススメの結論から言うと 保存しない に一票かと思います。

 理由

 1レコードのデータ量が多くなり、クエリに時間がかかる

画像ファイルは通常のカラムよりデータ量が多いため、SELECT、UPDATE、INSERT共に処理時間が多くかかります。
MySQLは最終的にテーブル単位の実ファイルにデータを格納します。
もし毎回画像データもSELECTした場合、大きなテーブル（ファイル）の中から該当レコードを読み込みます。
画像をUPDATEする場合、INSERTする場合も、通常のカラムではせいぜいvarchar(255)などに比べ、例えば4kb(4096byte)など、小さい画像でも、DBにとっては大きなデータになります。

故に 処理時間 は考慮した方が良いかな、と思います。

 DBのストレージ容量を圧迫する

画像を含むレコード数がどれくらいかわからないのですが、商品であったとして、継続的にデータが増えていくものとします。
この場合、データベースのサーバーの容量が 通常のレコードの容量の想定を超えて 増加することになります。
WebもDBも1つのサーバーで動く小規模システムならば許容できるかもしれないのですが、

• サムネイルも保存したい
  などとなれば、さらに容量を圧迫する場面もあるかもしれません。

また、静的ファイルのデータ量と、テーブルのカラムに保存したデータ量では、若干ですがカラム保存の方が容量が多くなります。

 WebとDBを分割しようと思った時に弊害がある

• 将来的にWebとDBを分ける
• やっぱり画像やJavaScript、CSSなど静的ファイルは別の場所に置きたい
  などが発生した場合、容易に分けられなくなる、と言う弊害もあるかな、と思います。
  テーブルに格納されている画像データを片っ端から読み込んでは、画像の実ファイルに保存する。
  そう言った処理を  存在するレコード数 だけ処理しなければならない場面が将来的に想定できるならば、画像は最初から静的ファイルで保持した方が良いかな、と思います。

 ネットワークを圧迫する

また、ネットワークを流れるデータ量も多くなります。
WebサーバーとDBサーバーを分けている（もしくは将来的に分ける可能性がある）場合、Web←→DB間のネットワークを圧迫します。
Web側に多くリクエストがきた場合、DBで捌ききれずにWeb、DBいずれかがタイムアウトを起こし、ユーザーの画面が真っ白、と言うことも起こりかねません。

DBからネットワークに流すデータ量は少なければ少ない方が良いと思います。

 メンテナンス性が低下する

画像は一度保存したら絶対に更新しない、と言うわけではないと思いました。
その場合、通常ならばサーバーに画像をアップロードすればいいはずが、必ずプログラムなどからSQLを実行しなければならない、と言う 何段階も余計な手順を踏む 必要性が出てくることが想定されます。
また、SQL実行するので、余計なバグで他のデータに影響を与える可能性もあります。

静的ファイルは ピンポイントにサクッと更新できる 状態にしておいた方がいいかな、と思いました。

 キャッシュしにくくなる

ユーザーのブラウザ上での読み込み速度向上などの為に、画像を含む静的ファイルをキャッシュとして配信したい場面が出てくることがあります。
その場合、静的ファイルであれば簡単ですが、DBに保存されている場合は違う手順を踏む必要があるかと思います。
踏む手順が多くなると、それだけ運用効率も下がり、保守性が低下したり、いいことがなかったりします。

今後の運用・保守も視野に入れ、設計することをオススメしたいです。

 利点

僕自身、これと言った利点が思い浮かびませんでした。
強いていえば

• SQLだけで画像も含めた商品データが取れる
  くらいかと思いましたが、それならば 画像は静的ファイル にして、 相対パスをテーブルのカラムに保持 の方が現実的かな、と思いました。

ご参考になれば幸いです。
間違いなどあれば指摘いただければ助かります。

私自身の意見ではないのですが、Oracle さんの資料で面白いものがありました。
データベースに画像を格納するメリット

こちらの資料を読むと、パフォーマンスやデータサイズで DB 保存を諦めるのは、判断基準としてあまり適切ではなく、優位点（管理やセキュリティ、バックアップ/リカバリ等）を考慮すべきですよ。といった内容になっています。
MySQL ではなく、oracle 資料なので微妙ですが、参考まで。

システムの保守などをやる場合、DBのデータを手入力で修正したりするケースが出てきます。
そういう場合、DBに格納されているデータは「Selectの結果が視認可能」で「Update/InsertがシンプルなSQL文で実行可能」な方が作業しやすいです。

という訳で個人的には「データベースに画像を保存しない方がいい」に一票。

予算的、システム的、政治的に可能であれば、いちばんのおすすめは、保管先をDBでもローカルのディスクでもなくオブジェクトストレージ（AWS S3など）にすることです。

保存するときも容量不足などを考えずに済みますし、パブリックで良ければそのままHTTP配信もできてしまいます。という感じに、ファイル管理からほぼ解放されるので、かなり楽です。

ストレージの容量によるのではないでしょうか？

例えば Web サイトを公開するために自分が使っているレンタルサーバーですと、3 GB の容量の内 DB サーバに使えるのは 300MB のみですが、そのような場合は画像本体は Web サイトのどこかのフォルダ、DB サーバーに保存するのはその画像へのパスにせざるを得ません。

私はどちらも一長一短だとはおもいますが、質問者さんの状況であれば、「データーベースには画像を保存しない」ほうをおすすめですね。
理由はリファレンスの多さの違いです。何か追加機能を実装しようとしたときに、RDBに保存する設計より、ファイルサーバーに格納するほうが圧倒的に情報は見つかりやすいと思います。ま、ケースバイケースですが。

RDBに保存するすたいるは後々トライするくらいでいいかと思います。

管理の面から考えると格納しない方をおすすめします。
DBに保存するのは画像があるパスに留めた方が良いかと思います。

基本的にデータベースに画像は保存しない方がいいです
SQLで画像データいじるなんてしません
逆にデータベース云々抜きにして画像をどうこうしたい場合はあります

画像の中身に応じてサーバー側の処理を分岐なんてそうそうしないはずです

SQL側で画像が不要な場合や不要な行は取り出さないように
っていうのを徹底しないとメモリの負荷が半端なくなります
それでなくてもサーバー側の処理が画像のデータを
全部読み込むまでストップしちゃいます

データベースに画像を入れる方が色々スムーズと言えるのは
プログラムで動的にQRコードやアイコン程度のサイズの画像を
生成する場合ぐらいと思います

たとえば一切のファイルI/Oを認めたくないという運用ポリシーがあるなら
選択肢はDB上に保存しておくしかないかもしれません。

そうではないならDBからデータを抽出するよりファイルI/Oの方が効率がよいので
ファイル本体をDBにおくメリットがほとんど感じられません。
バイナリデータの中になにか特殊なデータを含むものを検索することは
運用上考えられませんし、もしそれをやるとなるとDB自体のパフォーマンスは
あまり期待できません。

結果として画像本体はデバイス上にファイルとしておき、必要に応じて
その詳細情報はDBに転記しておくのがまっとうな使い方になると思います
サイズ、ファイル名、長さ、高さ、content-type、登録日、管理者などなど

設計次第ですが、「直接DBに保存しない」派です。

私がよくやる設計ではこんな感じ。

• アップロードした画像の置き場は決めておく（1ディレクトリに集中しすぎないように分散）
• アップロード時に画像をリネームして命名規則（例えばレコードのIDやカテゴリ名など）に則る

こうすると、拡張子文字列だけを保存しておくというやり方になります。
また、拡張子まで限定した場合はそれすら不要にできたりします。

他の方が仰るように容量の問題や速度の問題、処理上の問題もあると思いますので、
仕様や設計によって決めるのが良いでしょう。
商品情報とのことなので、一般的に閲覧可能なものでどんどん増えていき、また削除や更新もされるでしょうから、
DB保存はおすすめしませんね。

自分はデータベースなど詳しく無いですが先日MSのSQL Serverの新機能でデータベースからディープラーニング出来るようになりました！とか言っててそれなんの意味があるのと思ったんですが上にも上がってるようにデータベースサーバーのセキュアな仕組みを画像などにも適用して格納し、それをそのままディープラーニングの推論だか学習だか忘れましたがキックできるということらしくなるほどと思いました。
関係ないですが自分はバイナリの一定のサイズのものはAzureのBlobに突っ込んで安くしたりしてますね。用途によってはどぞー。

もう解決してしまってますが・・

画像の更新・参照頻度が低ければDBに入れるのもアリだとは思います。
が、画像データを扱うとデータ量や転送量の問題があるので、外部に置くのが良いかなと思います。

自分なら、画像自体はS3に保存してしまって、DBにはそのS3のパスを保存しておく。
参照が多い場合はCDN経由で画像を表示出来るようにしておく。
等の選択をするかなぁと思います。