How does MySQL store data

前端 未结 4 1809
-上瘾入骨i
-上瘾入骨i 2020-12-15 03:26

I looked around Goole but didn\'t find any good answer. Does it store the data in one big file? What methods does it use to make data access quicker than just reading and wr

4条回答
  •  盖世英雄少女心
    2020-12-15 03:56

    Does it store the data in one big file?

    Some DBMSes store the whole database in a single file, some split tables, indexes and other object kinds to separate files, some split files not by object kind but by some storage/size criteria, some can even entirely bypass the file system, etc etc...

    I don't know which one of these strategies MySQL uses (it probably depends on whether you use MyISAM vs. InnoDB etc.), but fortunately, it doesn't matter: from the client perspective, this is a DBMS implementation detail the client should rarely worry about.

    What methods does it use to make data access quicker them just reading and writing to a regular file?

    First of all, DBMses are not just about performance:

    • They are even more about safety of your data - they have to ensure there is no data corruption even in the face of a power cut or a network failure.1
    • DBMSes are also about concurrency - they have to arbiter between multiple clients accessing and potentially modifying the same data.2

    As for your specific question of performance, relational data is very "susceptible" to indexing and clustering, which is richly exploited by DBMSes to achieve performance. On top of that, the set-based nature of SQL lets the DBMS choose the optimal way to retrieve the data (in theory at least, some DBMSes are better at that than the others). For more about DBMS performance, I warmly recommend: Use The Index, Luke!

    Also, you probably noticed that most DBMSes are rather old products. Like decades old, which is really eons in our industry's terms. One consequence of that is that people had plenty of time to optimize the heck out of the DBMS code base.

    You could, in theory, achieve all these things through files, but I suspect you'd end-up with something that looks awfully close to a DBMS (even if you had the time and resources to actually do it). So, why reinvent the wheel (unless you didn't want the wheel in the first place ;) )?


    1 Usually though some kind of "journaling" or "transaction log" mechanism. Furthermore, to minimize the probability of "logical" corruption (due to application bugs) and promote code reuse, most DBMSes support declarative constraints (domain, key and referential), triggers and stored procedures.

    2 By isolating transactions and even by allowing clients to explicitly lock specific portions of the database.

提交回复
热议问题