As for why it's slow ... the reasons are very simple and boil down to "programmers don't understand databases". I assume you're using MySQL, but the points are applicable to most other RDBMSes.

1. I'll bet you don't have an index on the aggregated_area column.
2. I'll bet that column is TEXT, meaning that even if you are indexing it, you're indexing it improperly. You have to index the first N characters (up to 255 for MySQL).
3. If you're using LIKE to find substrings, then you'd be better off breaking that column out into a separate table and indexing that table.
4. If they do have % or _ signs and you have them as the first character, then indexes are completely ignored. (They have to be, if you think about it.)

The bottom line is LIKE has extremely poor performance characteristics and should be avoided whenever possible. If you're using LIKE, you had better have exhausted all other possibilities, like normalization.

First, the whole purpose of prepare/execute is so the sql api only has to parse the statement once -- well, that and the security concerns... So, I moved that up before the foreach().

map {} () is awesome.... try to get the hang of that. They suggest using as few print statements as possible, so I compounded that. I removed the undef @row, as I believe it's implied at the end of the block.

Lastly, if nothing is turning up in your output file, check your open() to see if you have the ">" in the filename.

Why did I rename all those default vars? Take it from someone that's been a perl nerd for a long time... it's better to name your perl vars longwindedly!

Meh, here's your snipped the way I might do it:

my $sth_C = $dbh->prepare(
    "select * from result_storage_keep 
     where aggregated_area like ?")
     or die "Couldn't prepare query: " . $dbh->errstr;

foreach my $area (@Geo_areas) {
    next unless $area;

    $sth_C->execute($area) 
        or die "Couldn't execute query: " . $sth_C->errstr;

    while (my @row = $sth_C->fetchrow_array) {
        print OUTPUT_FILE 
            join("\t", map {$_ ? $_ : "''"} @row),
            "\n";
    }       
}
[download]

Also, since you seem to be printing it all to the same file anyway, why not shorten it even more and do something like this:

# this only works if this array is small-ish
my $areas = join(", ", @Geo_areas);

# interpolating can be dumb ... 
# unless you trust the data in @Geo_areas...
my $sth_C = $dbh->prepare(
    "select * from result_storage_keep 
     where aggregated_area in ($areas)
     order by aggregated_area")
     or die "Couldn't prepare query: " . $dbh->errstr;

while (my @row = $sth_C->fetchrow_array) {
    print OUTPUT_FILE 
        join("\t", map {$_ ? $_ : "''"} @row),
        "\n";
}
[download]

'..._area LIKE ?;'
[download]

You can use order by in the select query so that the Implicit sorting is done in the select query itself.

foreach (@Geo_areas) {

      $_ or next;

      my $Return_results = "Select * from Result_storage_keep where Ag
+gregated_area LIKE '".$_."' \;";
                
      my $sth_C = $dbh->prepare($Return_results) or die "Couldn't prep
+are query: ".$dbh->errstr;
      
      $sth_C->execute() or die "Couldn't execute query: ".$sth_C->errs
+tr;
      
    while (my @row = $sth_C->fetchrow_array) {
    foreach my $val (@row) { 
      
      $val = '' unless defined;
    }
    print OUTPUT_FILE join("\t", @row);
    print OUTPUT_FILE "\n";
    undef @row;
      }
  }
[download]

Using a named variable on foreach loops is often a good idea from a readability standpoint, but the parent reply makes it sound like it will change the behavior. This is not true. foreach automatically localizes the index variable if it is a global. See perlsyn.