Specifically _UserTableStat and _UserIndexStat but there are others that could desperately use an index.
Adding indexes won't fix this. They aren't "real" tables. With the user table stat stuff you can actually work out the ID of the records you are after because they are actually created at user logon in a particula order and you know how many there will be because of the startup parameters. I have written some code which is super quick at reading these which I'm happy to share. Send me a message if you're interested.
Random thought: If a developer can come up with a mathematical method to derive the RECID -- presumably something close to (connection ID * number of tables (tablerangesize?)) + [relative to -basetable?] table ID? -- then the engine could provide a "virtual index" for equality matches on those fields (connection ID and/or table ID).
In theory. Or else post the code in question to the KB and done. Current example is presumably less performant: