I'm not sure what your Cars table represents but this code updates the Cars table with idSize from a text file by matching idCars.

#!perl
use strict;
use DBI;
my $dbh = dbh(); # connect

my $sql = 'UPDATE cars SET Size = ?
           WHERE idCars = ?';
my $sth = $dbh->prepare($sql);

# update
while (<DATA>){  # or filehandle
  chomp;
  my ($idCars,$idSize)  = split /\s+/,$_;
  $sth->execute($idSize,$idCars);
}

# show result
my $ar = $dbh->selectall_arrayref('SELECT idCars,Car,Size FROM Cars');
printf "%5s %-15s %5s\n",@$_ for @$ar;

# connect
sub dbh{
  my $database = "database"; my $user = "user"; my $pw = "password";
  my $dsn = "dbi:mysql:$database:localhost:3306"; 
  my $dbh = DBI->connect($dsn, $user, $pw, 
   { RaiseError=>1, AutoCommit=>1 } );
  return $dbh;
} 

__DATA__
1  1
2  2
3  3
4  3
[download]

This would occur, if , in your example, the same model CAR was available in many "Sizes" - i.e. perhaps Compact, Sedan, and hatchback.

Now, if you wanted to keep the database "normalized" - i.e. have no duplicate primary data, you would set up CARS and SIZES as you started with, and add a table, say "MODEL", which contained a carID and a SizeID, and perhaps a date-introduced.

Now, for each car, say MiniCooper, you add a record in "MODEL" for each size it offers.

Actually creating a database would make this more clear.

Anyway - all this stuff is old-school "relational" database" modelling.
"NOSQL" databases are in fashion now, and these store key-value pairs. However, it does help to understand the old structured databases, even if you use one of these new-fangled things(My favourite is ElasticSearch).