MySQL – How to Determine RAM Usage of a Query

I wish the creator of that tool would toss that line. It unnecessarily scares people. And the number it gives is both too small and too large.

But, in your case, it there is a real danger. If you had just 3 queries running that were nasty enough, they could be asking for 2.4GB -- more than your RAM!! This is because tmp_table_size and max_heap_table_size are set to 800M. Change them to, say, 20M. Queries will still work, but they may spill to disk more often. More importantly, you want swap or crash.

Fragmented tables -- bogus. Virtually all tables are fragmented. OPTIMIZE TABLE is almost never worth doing.

But...

key_buffer_size of 1.5G in 2GB of RAM is really bad. 300M is about right if you are using only MyISAM. The key_buffer is for MyISAM indexes. You need to leave room for data, which is cached by the Operating System.

Since the Query cache hit rate is so low and the size is dangerously high, you are better off turning it off and using the RAM for other stuff. query_cache_type = OFF and query_cache_size = 0.

Since you have a "tiny" amount if RAM (2GB), you should probably lower max_connections. Look at the STATUS value of Max_used_connections to see the high water mark since last restart.

Edit

1. Upgrade to a 64-bit MySQL
2. Configure key_buffer_size and innodb_buffer_pool_size in my.cnf to the amount of RAM you have. Guidelines: http://mysql.rjweb.org/doc.php/memory
3. See how things are going; come back to us for more help (and/or abuse) if needed.

AWE is not a "process", it is an API used for memory allocation. Quick googling shows that SQL Server may be using that API to allocate its bufferpool pages. It must be a quirk of RAMmap to show this under the AWE category.

I think it is pretty normal for a database server to show high memory utilization ratios, otherwise unused memory would be simply wasted.