MySQL setting that affects memory
low memory &lt; 1G+- available, so the goal is not to exceed 512mb of total mysql usage


I'll assume 0.5GB.

max_connections=1501 #we only use up to 200, setting this to avoid too many conn error


That will chew up a lot of RAM that you do not have.  I would set it to no more than 50 and then work on making sure the applications throttle back how many connections they ask for.

If you have more than, say, 10 active threads, you could encounter them stumbling over each other -- this leads to performance issues of its own.

innodb_buffer_pool_size=128M


This is probably all you can afford in that tiny RAM.  More than that will lead to swapping; less than that could lead to cases where it simply can't get the job done.

innodb_log_file_size=64M


That's a disk file limit; it has no impact on RAM allocation.

innodb_log_buffer_size  16777216


is in RAM.  Cut that back to 4M.

The 80% rule is fine if you have more than 4GB of RAM.  A better rule is "80% of available RAM".  The issue is that you need the OS, the mysql code, and many other caches, buffers, etc.

max_allowed_packet=2G #due to large queries during data migration


Duh?  That is allocated in RAM, but you don't have that much RAM??  Imagine how much swapping will happen!  If you are loading a dump from mysqldump, rebuild the dump so that it does not build huge INSERT statements.  If you have 2GB BLOBs, you may be in big trouble.  Then cut that back to 32M (I guess).

innodb_buffer_pool_chunk_size is relevant only if you dynamically resize the buffer_pool.  (You are not likely to do this.)

Toss the query cache:  query_cache_size = 0 and query_cache_type = OFF.

tmp_table_size and max_heap_table_size -- Set to 1M.  These may be allocated once per connection or even more often (in the case of a complex SELECT).  MySQL has a fallback if these are "too small", so you won't lose functionality.

sort_buffer_size -- 4M

There may be more.