Why is a 'Select distinct limit 100' using tmp tables?
There are multiple ways that SELECT DISTINCT col FROM ... LIMIT 100 can be performed:

Case 1:  Create a temp table with all rows of col, sort it, then peel off the first 100 (de-dupping as it goes).

Case 2:  Build a hash in memory, read col putting it into the hash, stop after 100.  (Fast.)

Case 3 (if there is INDEX(col)):  Leapfrog through the index.  This effectively takes 100 BTree dives into the index.  (Fast, even if few distinct values.)

Which will it do?  It depends on the version, the data, the existence of an index, etc.  Note that 5.1 is antique; you should plan to upgrade to 5.5, then 5.6, then 5.7.  (8.0 is also available, but not "GA".)  The Optimizer has changed a couple of times in this area, so I cannot say what your version will do.

If you are going to do this for all columns, consider, instead,

SELECT GROUP_CONCAT(DISTINCT col1),
       GROUP_CONCAT(DISTINCT col2),
       ...
    FROM TABLE;


(No LIMIT.)  This won't give you exactly 100 of each, and it will probably give you only the alphabetically/numerically first several (1024 bytes' worth) of each list, but maybe that is good enough.  It is probably faster than column-by-column.

See also ANALYSE() (spelled that way).