I got a doubt I have seen reading mysql data is slower in case of large tables...I have done lots of optimization but cant get through..

what I am thinking is will it give a better speed if I store data in a piece of file??

off course each data will be a separate file. so millions of data = millions of file. I agree it will consume the disk space... but what about reading process?? is it faster??

I am using PHP to read file...

+1  A: 

To answer the topic, yes.

By which I mean that there are so many (unmentioned) factors that it's impossible to unequivocally state that one will be faster than the other every time.

Ignacio Vazquez-Abrams
+4  A: 

As long as your tables are properly indexed and as long as you are using those indices (that's right), using a relational DB (like mysql) is going to be much faster, more robust, flexible (insert many buzzwords here), etc.

To examine why your queries' performance does not match your expectations, you can use the explain clause with your selects (http://dev.mysql.com/doc/refman/5.1/en/explain.html).

Unless the DB server is underpowered or overloaded.
Ignacio Vazquez-Abrams
@Ignacio Vazquez-Abrams: ..or turned off :P But yes, I do see your point
+2  A: 

Reading one file = fast.

Reading many / big files = slow.

Reading singular small entries from database = waste of I/O.

Combining many entries within the database = faster than file accesses.


It depends on a lot of factors, not least of which is what kind of file system you're using. MySQL uses files for storage anyway, so read speed isn't the issue -- the biggest factor will be how fast MySQL can find your data, compared to how fast it can be looked up in your filesystem.

Generally, though, MySQL is quite good about finding data quickly -- after all, that's its purpose in life. So unless you have a really good reason why the FS should be much faster, stick with the DB and check your indexes and such.


By choosing a custom file storage system you will lose the benefits of using a relational database. Also your code might not be easy maintainable.

Nonetheless, there are many who believe that relational databases offer too much complexity at the cost of speed. Have a look at the NoSQL entry in wikipedia and read about possible alternatives.


It depends on what kind of data you're storing. Structured data is usually much faster and more flexible/powerful to read using SQL, since that's exactly what its made for. If you want to search, filter, sort or group by a certain attribute, the index structures and optimizations of a DBS are appropriate.

However, when using a DB for storing large files (BLOBs), which contain unstructured data in the sense that you are not going to search, filter, sort or group by any part of the files, then these files just blow up the database size and make it slow. There is an interesting study by Microsoft on this topic (just have to find the link yet). This study is the reason why Microsoft introduced the External BLOB storage in their SQLServer, which basically means what you asked: The BLOBs are saved in files outside the database, because they measured that access is much faster that way.

When storing files (e.g., pictures, videos, documents...) you often have some metadata on the file which you want to be able to use with a structured query language like SQL, while the actual files don't necessarily need to be saved in the database.

+1  A: 

Reading from a dbms (MySQL is one) is faster in most cases, because they have built in cache that will keep the data in memory, so next time you try to read the same data, you will not have to wait on the incredible slow hard drive.

A dbms is essentially reading from your hard drive + a cache to speed things up (+ some data sorting algorithms). Remember, your database is stored on your hard drive :)

Thomas Winsnes