views:

53

answers:

2

I'm currently using mysql w/ PHP because that's what I learned and haven't ever had to use anything else. In my current project, I have a database w/ 10 million rows and about 10 columns and have found it to be very slow when I do complex calls, both in a local (windows) environment as well as production (linux) environment. Both servers have over 10GB of ram. I've already got Zend AMF installed and so all data transfer is binary.

I am self taught and have never had anyone teach me the ins-and-outs of efficient dbm. My first thought would be to break the DB into chunks and then change all my php code..seems like a lot of hassle and subject to error in the php code...is there a better way I am not aware of?

My UI is flash-based and I am willing to change the middleware if it means a significant increase in speed. At this point I really only know PHP as a middleware.

I don't want to learn another db at this point and figure that there has to be some tricks of the trade to optimizing my performance but wanted to get some ideas before I hacked away at my DB.

fyi: the database is read only from a user's standpoint. users are NOT entering any new data into the database. Also, of the 10 million rows in the database, there's only about 200,000 that are heavily used. (I don't know WHICH 200K rows are heavily used as recording this info would probably slow down my db even more).

Each call is something like:

SELECT   name, id, address 
FROM     table 
WHERE    date_added=? 
LIMIT    ?,? 
ORDER BY no_children ASC

... and various other "select" statements.

+2  A: 

Do you have an index on the date_added field? If not, create one, and try again:

CREATE INDEX ix_date_added on table (date_added);

You may also be interested in checking out the following article from the MySQL Reference Manual:

You should also try to use EXPLAIN in front of your SELECT statements to see if the queries will use any of your indexes. This is often the first step towards proper troubleshooting of performance problems.

Daniel Vassallo
and you still will get the filesort to satisfy `ORDER BY` clause.
zerkms
A: 

this answer is also answer to @Daniel Vassallo's one:

CREATE INDEX ix_date_added_no_children on table (date_added, no_children);

is more correct

zerkms
@zerkms: Yes, a covering index is better, in general. I avoided this topic in my answer to keep it simple, especially since there will still be a huge performance gain if the OP does not have an index on the `date_added` field.
Daniel Vassallo
Will a covering index, then, limit the TYPE of Select statement I can use? What if I want to also let the user search the db w/ different criteria (ie search by sex, age, etc). Will having multiple covering indexes limit my performance?
ginius
From this presentation http://assets.en.oreilly.com/1/event/21/Covering%20Indexes_%20Retrieving%20Data%20Without%20Accessing%20It%20Presentation.pdfit looks like I should consider converting to InnoDB as my select statements get more complex.
ginius