SQL Server Kernel architecture profiling

We do management software, the main core is in the data storage management. So database design is our most important. In order for our management software to be stable, scalable, excellent performance, traceable error, scalable deployment, plug-in operation, we often develop our own management software development platform. We always want to learn other people's development platform (such as Ufida or Kingdee or SAP), but we always sigh management software business processing details, but the database management software is simple SELECT, INSERT, DELETE, update four commands on the deal. We wish we could make an architecture one day, and we can do the management software so easily. We tend to study the architecture of others, but we forget the structure of the database we are most familiar with around us. Therefore, today, I would like to lead you to dissect the database structure, to explore the structure of the database idea. And I myself, only familiar with SQL Server this kind of database product, so I take SQL Server to analyze.

Before I talk about the internal workings of SQL Server, I find it very necessary to introduce the history of SQL Server.

Let's stand in 1999 and see what the state of the computer database industry is.

Oracle 8i was released in September 1998 in 1999, and the Chinese version may not have arrived in China for 1999 years. Oracle 8i supports writing stored procedures in Java, supporting XML, and supporting Linux.

January 1999, SQLSERVER7 officially released. SQLSERVER7 refactoring the entire database engine (equivalent to rewriting SQL Server). SQL Server for the first time integrity of the support of the row lock (there is no mistake, how people used to use the database products.) In 1988, Oracle6 supported row locks. In 1988, Oracle began to develop ERP products. Who said Oracle is a layman in ERP, you can refer to this.

Look at the previous version of both of them. If you are late in the profession (after 2000), you may be more surprised by the following words.

1992, Oracle7 released. There are stored procedures, triggers, referential integrity checksums, distributed transaction processing. (Goodness, Oracle7 have these things).

1995, SQLSERVER6 released. SQLSERVER6 is Microsoft's first real sense of the database product (really burst, we did not think SQLSERVER6 is Microsoft's first database products, that version 6 before 5, 4, 3, 2, 1 how to spend it). Because in 1994, Microsoft and Sybase broke up (Sybase was the first C/S database product to run on PCs). In order to enter the database product field, Microsoft has no experience, so and Sybase work together (at that time, Microsoft is the world's largest software company, Microsoft 1986 listing. Sybase has a product that lacks money. Microsoft has a shortage of products and money. So clicked). Until 1994, Microsoft did not need Sybase (has learned the database technology), Sybase also feel that Microsoft is too ambitions, so cooperation split. Microsoft began to make its own database.

The end of history. Let's have a closer.

Many entry-level to do management software, SQL statements play a skilled, from the subquery to have to the crosstab statistics SQL can be made, or even stored procedures can write more than 2000 lines, cursors, custom functions, triggers, constraints used by the dazzling. In the SQL query, you can use SQL analytics to optimize indexes, SQL profiles to track SQL, and even monitor SQL Server memory, CPU, thread, I/O running state in the performance viewer, and even gloat over the use of DBCC.

You are so familiar with SQL Server and so unfamiliar with SQL Server.

Today I'm going to give you an architectural perspective on SQL Server architecture and principles. Just a blog must be more than a few, deep layer may need to serial several articles or even a large brick book can be said complete. However, I hope that my blog post can give you a chance to see SQL Server from an angle that you have never thought of before.

SQL Server, as a database product, I personally think that the most important is two big chunks: the storage engine and the query engine.

Other logs, transactions, locks, indexes, and so on, work around them.