fenway

Just dump into a temporary table, and then you can use INSERT INTO.. SELECT WHERE... as usual.

I don't follow.

Show us the query you have now.

Well, those previous developers left you with a giant mess. If you add an index on (statusdate), queries 1 and 2 should be noticeably improved. For query3, try ( batch, depbank ).

You don't have any indexes -- that's the problem. Why are you querying on parts of a column?

LOAD DATA INFILE works well.

I don't see why it's not using any key.

Well, at some level, "users" and "picks" are completely different entities, so it's logical to keep them separate. What if you later change you design to allow for multiple picks per week? With 2 tables, that's easy -- with a combined table, that's all but impossible. If you store your entities cleanly, your application can mature without difficulty. If, instead, you choose to store the current relationships you require, you'll never be able to change them.

There is a freelancing PHP forum.

Yeah, that's the problem -- examining 900K rows to return 2. What are those queries -- can you post them, and their accompanying EXPLAIN?

I don't understand what that means.

Show us the EXPLAIN.

10? You said 2.

Clearly not.

Doubtful.

Sorry, what's broken?

You want a random 2 of those 4 values?

Uh, not RIGHT JOIN -- so uncoventional.

Then you need to wrap this is yet another SELECT.

Basedir off the root?

I don't know what a system is, for starters. But you're not showing any errors, any output from the slow query log, any examples of common queries, traffic, etc.

Don't play with magic auto-increment values -- leave them alone. Your numbering doesn't matter -- and if it doesn't, use another column, or count yourself.

InnoDB?

A temporary table just to sort????

Wrong how?