This is a known issue. While it does not really cause a major concern given that MySQL is perfectly capable of handling the amount of rows, it does cause some other issues elsewhere.

As for not needing the cache is open for debate. It has nothing to do with speed of FC or Auno, but rather about not hitting them up uneccecarily.

On a general basis i can say that this is one of the things i would like to greatly improve on for BeBot 0.7/0.8 allowing us to discard entries that have not been accessed, and thus not updated for x hours/days, as well as making the system smarter so that roster updates and whois updates are carried out as early as possible after FC updates information, while at the same time making sure we dont have thousands of bots hitting up the servers at the same time.

The script shouldn't do 55k queries when running, most chars should be covered by org membership.

The script does read org rosters first, and updates all chars in there. Before optionally going over everyone else left over.

Personally a "last queried" column would be a contradiction of the idea behind the cache. I added it after funcom had problems with their character information, which meant all bots relying on that information had insane lag while unsuccessfully trying to look up the information.

If you don't run the update script the cache shouldn't grow that fast as it will only lookup characters actually queried by the bot. And it will only update their entries if the are queried again after 24h (I think that's the default, it's actually controlled by a setting).

Besides, what's the problem with 55k entries in the cache? It can't really be a space problem, the 4-5mb shouldn't even register on any current harddisc.