What are a lot of MySQL queries per page?

My tables are correctly done trust me. I planned them out and everything using an entity relationship model program.


Yeah now I see what you're talking about with the caching. I didn't really visualize it in my MySQL query function, but that is awesome man. I can write my own version sort of like that for my database class now.

The thing is, I don't see too many queries I'd want to use it on in that header, only like 5. But I know it will come in handy for a ton of queries on my site. Like for example, I have a site configuration table in my database for when I login and want to make changes, I'm sure that could be delayed like 2 to 5 min at the least unless it's something important.

The only thing is a lot of the queries that are in my main include file are user specific and need to be there up to the minute.

I did have some issues with calling the same queries a lot, like this user authentication function that wanted to know the permissions of a user. So I made it so it only called it one time and then stored the permissions in a variable and then if the variable had it in it, it wouldn't call the query again. I had another idea though that would be useful instead of making certain variables for certain queries I thought of just making my mysql_query() function store the result of queries that are done during the current page load into a variable temporarily and then if the same exact query is called before the end of the page load then just use whatever result was stored. Basically the same thing you guys showed me except only for the current page load so I could reduce the possibility of calling the same query for queries that are not normally cached for 2 min or whatever. The only problem is it still has the pitfall of: If in my code I do a SELECT, then update that table, then do the exact same SELECT again before the end of page load, so nvm I don't think that will work... unless I some how unset the saved results variable IF someone updates, deletes or inserts to the same table between selects. Any ideas?

I've never actually heard anything about this stuff before, but it's pretty cool optimization. Any other cool abstract optimization tricks you guys aren't telling me? I taught myself PHP from google, so I highly doubt that I know everything (cept for the database entity relationship notation stuff, learned that from school).

Similar to Camperjohn - a class which first queries DB and writes the query to a cache file using serialize function. No further queries of DB are necessary until cache file expires(default of 1 hour).




Then instantiate the class

That's a pretty good example too man. I think I've got it down to those 14 queries and then 5 of them will be cached. I think that's reasonable, I don't think there are any extra queries that I can combine. I know how to query multiple tables at once and join and all that.

Hey, I implemented that caching system (the first one) and I used it on a query that checks to see if an IP or User Account is banned, but since it's unique data for every user, pretty much it makes a new .mysql cache file for each user/IP. They're only like 1KB each, but you think it would be smart to have like X amount of files per X IP's that visit my website!?

What you could do, it then do mysql_cached("SELECT * from BANNED_IPS");

Then see if the users IP is in that array. This would result in ONE cache file from the database. and would not hammer the database when a new user arrives.

This is of course assuming you dont have a million banned users.

Yeah I'm an idiot, why didn't I think of that. I'm just not use to doing that kind of stuff when I query. Good idea thx man. Yeah I only have like 1 banned thing right now anyway.

Only thing is, I don't really think I can do that with a lot of my user based queries.

How many queries you have depends on the complexity of your application. 100 queries is on the high side, but not particularly huge. I have heard of queries going up to a couple of hundred per page load.

I think Wordpress typically does around 15-20 queries per page load. That is not a lot.

Are you serious ... ? wow, I would never have thought it that much ... where did you get this information?

It depends how advanced your site is, if you try to cache the queries you can cache and combine queries that you can combine on your site, then you did good in my book regardless of the number. I think I've learned that by now.

Ozzu is around 8-10 queries per page load with 2-3 being cached usually. The more traffic you get every query you can reduce it by helps (as long as you are doing your queries smart still, sometimes less is not better). I use the explain statement to make sure:

http://dev.mysql.com/doc/refman/5.0/en/explain.html
http://dev.mysql.com/doc/refman/5.0/en/ ... plain.html

It is important to look at how many rows are scanned from each table and taking the product of that. That gives you a good idea of how many rows MySQL has to examine to execute the query. The smaller you keep that number the better.

Also the join type is important with system, const, eq_ref, and ref being the best. If you see "All" that is usually not good.

What I recommend if you choose to optimize or reduce your queries is to first figure out how long it takes for your current queries. Then once you make your changes you can see if the overall time goes up or down. If the time increases then you should go back to how you were doing it. If the time is reduced then you would use the new queries.

I would highly recommend you do not do that ever, as that increases the number of queries on your page dramatically. If your first query returned 30 results, and then you did a separate query using each of those results that is another 30 queries you just added. Ouch.

A better soluttion is to take the results from the first query and store them in an array of some sort. Then you could take the results from that and use it in your 2nd query to get everything you need.

For example, lets say I needed 30 widgets from the database and they each have their unique ID. What you could do is construct your query to first get those 30 ids and store them in an array which we will call "widgetIDArray". Then if you need the colors of the widgets which are stored in another table, you could do something like this for your sql statement:



I have now effectively reduced the queries from 31 to 2.

Thanks for the tips A LOT, I actually took an entire database college course since I started this topic too LOL... I have a lot of optimization to do, A TON.

This thread is worth bookmarking for sure.

THANKS