Mysql performance related question for very large database
Q1:  A "database" is a collection of "tables".  The performance of a query on one table (or a few tables JOINed together) is entirely on the table(s) in the query.  Not other tables; not other databases.

Q2:  Do not make a bunch of tables.  If you have an index starting with ProductCode, then queries with WHERE ProductCode = 123 AND ... will be efficient.  (This question has been asked and answered many times - always the same way.)

innodb_buffer_pool_size should be set to about 20G.

If you usually fetch by ProductCode, then change

PRIMARY KEY (`id`),
KEY `ProductCode` (`ProductCode`),
KEY `AddedDate` (`AddedDate`)


to

PRIMARY KEY(ProductCode, AddedDate, id),
INDEX(id),
KEY `AddedDate` (`AddedDate`)   -- (no change here)


That will 'cluster' all 12K (avg) rows for a given product together, making many SELECTs run faster.

Does Table B have 8K rows?  Or 100K rows?  If there is one row per product, then get rid of id and change

PRIMARY KEY (`ID`),
KEY `ProductCode` (`ProductCode`)


to

PRIMARY KEY(ProductCode)


BUG! You have inconsistent CHARACTER SETs between the tables.  This can cause comparisons on ProductCode to not use an index!  (And hence be sloooow.)  (See ALTER TABLE .. CONVERT TO ..)

UPPER(Model) -- Don't use UPPER.  You have a case-folding COLLATION, so you will get the desired test without need for UPPER().

When I suggested PRIMARY KEY(ProductCode, AddedDate, id) above, including AddedDate was not important.  But looking at the SELECT, it is important, both in the WHERE and in the ORDER BY.