Answers to comments #1 and #4 seem to be contradicting each other: if you want to store information from several URLs the user has visited then you want that information to persist between requests. Otherwise, the only request counted will be the current one.
Based on answers to comments #1 and #3 you seem to be looking for the following (table?) structure: user_id, qa_request, access_count. In this case, q2a_request refers to the output of qa_request() function. user_id and qa_request would be a compound primary key. Each time a user bootstraps Q2A by accessing any page, you insert a new record with access_count with value 1 or increment an existing one.
Assuming I understood correctly, you need to take into account the following things about Q2A's cache:
1. The primary key is a compound key based on a type CHAR(8) and a cacheid BIGINT. In order for your schema to work you will need to turn your primary key into something (like hashing function) that would return a BIGINT to replace the cacheid
2. If you haven't configured memcached, then you will be reading/writing to a file (which is, in general, slower than accessing MySQL directly)
3. I don't see anywhere in the Q2A core code that Q2A expects plugins to use the cache table (not a big deal, though)
4. Q2A stores its cache index inside a table so accessing the cache will always force you to access the database first and then the underlying cache system you've configured.
My advice: create a custom table and use INSERT INTO .. ON DUPLICATE KEY UPDATE to keep track of each accessed qa_request per user. It will be faster, persist between requests and be simpler to develop.
Alternatively, you can store this in the session. This will be faster but you would only be able to access the data from the execution context of the request. It will not be persisted in a table for easy later use.
