StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The answer to your problem may lie in indexing appropriate fields in your database, most databases also <a href="http://dev.mysql.com/doc/refman/5.1/en/query-cache.html" rel="nofollow">cache</a> frequently served queries but they do tend to discard them once the table they go over is altered. (which makes sense)</p> <p>So you could trust in your database to do what it does well: query for and retrieve data and help it by making sure there's little contention on the table and/or placing appropriate <a href="http://dev.mysql.com/doc/refman/5.1/en/optimization-indexes.html" rel="nofollow">indexes</a>. This in turn can however alter the performance of writes which may not be unimportant in your case, only you really can judge that. (indexes have to be calculated and kept).</p> <p>The PHP extension you use will play a part as well, if speed is of the essence: 'upgrade' to <a href="http://www.php.net/manual/en/book.mysqli.php" rel="nofollow">mysqli</a> or <a href="http://www.php.net/manual/en/book.pdo.php" rel="nofollow">pdo</a> and do a -><a href="http://www.php.net/manual/en/mysqli-result.fetch-all.php" rel="nofollow">fetch_all</a>(), since it will cut down on communication between php process and the database server. The only reason against this would be if the amount of data you query is so enormous that it halts or bogs down your php/webserver processes or even your whole server by forcing it into swap.</p> <p>The table type you use can be of importance, certain types of queries seem to run faster on MYISAM as opposed to INNODB. If you want to retool a bit then you could store this data (or a copy of it) in mysql's <a href="http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html" rel="nofollow">HEAP engine</a>, so just in memory. You'd need to be careful to synchronize it with a disktable on writes though if you want to keep altered data for sure. (just in case of a server failure or shutdown)</p> <p>Alternatively you could cache your data in something like <a href="http://www.php.net/manual/en/book.memcache.php" rel="nofollow">memcache</a> or by using <a href="http://www.php.net/manual/en/function.apc-store.php" rel="nofollow">apc_store</a>, which should be very fast since it's in php process memory. The big caveat here is that <a href="http://www.php.net/manual/en/book.apc.php" rel="nofollow">APC</a> generally has less memory available for storage though.(default being <a href="http://www.php.net/manual/en/apc.configuration.php" rel="nofollow">32MB</a>) Memcache's big adavantage is that while still fast, it's distributed, so if you have multiple servers running they could share this data.</p> <p>You could try a nosql database, preferably one that's just a key-store, not even a document store, such as <a href="http://redis.io/" rel="nofollow">redis</a>.</p> <p>And finally you could hardcode your values in your php script, make sure to still use something like <a href="https://eaccelerator.net/" rel="nofollow">eaccelerator</a> or APC and verify wether you really need to use them 4 times or wether you can't just cache the output of whatever it is you actually create with it.</p> <p>So I'm sorry I can't give you a ready-made answer but performance questions, when applicable, usually require a multi-pronged approach. :-|</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload