Relational database summarizing

Relational database schema

Holistic thinking architecture

Architecture

• How to design a relational database

  1、需要一个文件存储系统（RDBMS）
  2、需要一个程序实例（对存储系统进行逻辑管理）
  包括:存储管理、缓存机制、SQL解析、日志管理、权限划分、容灾机制、索引管理、锁管理

index

• Why use an index

快速查询数据

• What kind of information can become index

主键、唯一键以及普通键等

• Index data structure

  1、生成索引，建立二叉查找树进行二分查找
  2、生成索引，建立B-Tree结构进行查找
  3、生成索引，建立B+-Tree结构进行查找
  4、生成索引，建立Hash结构进行查找

  B-Tree is defined:

  1, root node including at least two children

  2, each node in the tree contains up children m (m> = 2)

  3, except for the root node and leaf nodes, each node having at least another ceil (m / 2) (take maximum) children

  4, all leaf nodes are at the same level

  5、

  The definition of the tree - B +

  1, leaf node subtree pointer is not the same as the number of keywords

  2, non-leaf nodes of the subtree P [i], the key value point [K [i], K [i + 1]] subtree

  3, non-leaf nodes are used to index only data is stored in a child node

  4, all leaf node has a pointer to a leaf node chain

  hash index drawbacks:

  1, only to meet the "=", "in", you can not use range queries

  2, it can not be used to avoid the sort of operational data

  3, can not use part of the index key inquiry

  4, can not be avoided scan table

  5, after encountering a large number of Hash value are equal performance will not necessarily higher than the B-Tree indexes

  BitMap Index:

  Few index database support BIgMap

  结论:
  1、B+树的磁盘读写代价更低
  2、B+树的查询效率更加稳定
  3、B+树更有利于对数据库的扫描

• The difference between dense and sparse index index

1、密集索引文件中的每个搜索码值都对应一个索引值

2、稀疏索引文件只为索引码的某些值建立索引项 

InnoDB：

1, if a primary key is defined as the primary key index intensive;

2, if the primary key is not defined, the first index of the only non-empty table is a dense index

3, the above conditions are not satisfied, a hidden interior innodb generates primary key (dense Index)

4, the non-primary key value related to the primary key index is stored bit and its corresponding key, comprising two lookup

• How to locate and optimize slow queries Sql

  • According slow slow query log positioning sql

    show variable like '%quer%'   #查询数据库相关变量
    'slow_query_log' ——查看是否打开了慢日志查询功能；
    ‘slow_query_log_file’ ——慢查询日志的存放位置；
    ‘long_query_time’ ——多长时间的查询被定义为慢查询,单位为 秒；

    show status like '%slow_queries%';  #查看有多少慢sql

  • Explain the use of tools such as analysis sql

    explain + sql ;

    explain key fields:

    1、type:

    system> const> eq_ref> ref> fulltext> ref_or_null> index_merge> unique_sunquery> index_subquery> range> index> all index and the last two are all represented by a full table scan, sql need optimization;

    2、extra:

    When the field the following two think that the mysql can not use the index, the efficiency would be significantly affected, this should be optimized as much as possible.

    • Using filesort: mysql will represent the results of an external index order, rather than order index read content from the table. It may be sorted in memory or on disk. mysql can not be done using the index sort operation called the "Sort files
    • Using temporary: mysql indicate the use of temporary tables when sorting query results. Common in order by sorting and grouping query group by.

  • Sql sql modify or try to let go Index

• Joint index of the leftmost matching principle causes

1、最左匹配原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a=3 and b=4 and c>5 and d=6 如果建立（a、b、c、d）顺序的索引，d是用不到索引的，如果建立（a、b、d、c）的索引则都可以用到，a、b、d的顺序可以任意调整。

2、=和in 可以乱序，比如a=1 and b=2 and c=3建立（a,b,c）索引可以任意顺序，mysql的查询优化器会自动优化。

Cause:

mysql will execute joint index has left to right order by col1 (first field), col2 (second field), so the direct use up the second field can not use the index

• The index is established the better it

  1、数据量小的表不需要建立索引，建立会增加额外的索引开销
  2、数据变更需要维护索引，因此更多的索引以为着更多的维护成本
  3、更多的索引意味着也需要更多的空间

lock

Database lock Classification

1, according to particle size classification locks: lock table level, row-level locks, page-level locking

2. Click the lock level division: shared lock, exclusive lock

3, divided by the lock manner: automatic lock, an explicit lock

4, according to the operation can be divided into DML locks, lock the DDL

5, by use can be divided into optimistic locking, pessimistic locking

What about the difference between MyISAM and InnoDB lock regard is

• MyISAM is the default use of table-level locking, row-level locking is not supported;

  适合场景：
  1、频繁执行全表count语句
  2、对数据进行增删改的频率不高，查询非常频繁
  3、没有事务

• InnoDB is the default with row-level locking, and also supports table-level locking;

  1、数据增删改查都相当频繁
  2、可靠性要求比较高，要求支持事务

Shared lock (read of the database table)

In the concurrent circumstances, if a table (record) plus a shared lock case, the session can continue to add other shared locks;

In the concurrent circumstances, if a table (record) plus exclusive lock, both shared locks and exclusive locks are not together;

Exclusive lock (write operations on a database table)

In the concurrent circumstances, if a table (record) plus a shared lock down situation, both shared locks and exclusive locks are not together;

In the concurrent circumstances, if a table (record) plus exclusive lock situation under, both shared locks and exclusive locks are not together;

InnoDB query when taking the index is the row-level locks and lock gap

InnoDB query when not taking the index is the table-level locking

Close mysql InnoDB automatically commit the transaction function;

Close set autocommit = 0 # automatically submitted;

Manual shared locks: select xxxx lock in share mode;

Four characteristics of database transactions

• Atomicity

• consistency

• Isolation

• Endurance

Concurrent access issues under the transaction isolation level and at all levels

1, lost updates ( I also turned Affairs and others, submitted themselves when covering other people before me to submit updates in the update table data ) - mysql all transaction isolation level on the database level can be avoided

2, dirty read ( read data submitted by others do not ) - read-committed transaction isolation level above can be avoided

3, non-repeatable read ( first reading and second reading because nobody can submit a transaction, resulting in inconsistent data I read the same before and after ) - repaeatabe-read the above transaction isolation level to avoid

4, phantom read ( first reading and second reading because nobody can submit a transaction, resulting in the number of data I read inconsistent ) - serializable transaction isolation level to avoid

oracle default transaction level is: read-commit

mysql default transaction level is: repeatable-read

View isolation level of the database:

select @@tx_isolation;

Setting the isolation level rating:

set session transaction isolation level read uncommitted;

Note: SQL standard and different places that InnoDB storage engine REPEATABLE-READ (can be re-read) is used under the transaction isolation level Next-Key Lock lock algorithm, thus avoiding to generate magic of reading, which with other database systems (such as SQL Server) are different. So supported by default storage engine InnoDB isolation level is REPEATABLE-READ (can be re-read) already fully guarantee transaction isolation requirements, namely to achieve the SQL standard SERIALIZABLE (serialization) isolation level.

InnoDB Repeatable Read isolation level at how to avoid phantom read

Appearance: a snapshot reading (non-blocking) - pseudo MVCC

Current reading (plus CRUD lock):

select .... lock in share mode;

select ...for update;

update,delete,insert

Snapshot read (unlocked non-blocking reads):

select ...

Internal: next-key lock (line lock + GAP lock )

• Primary key index or unique index will lock it with Gap
  • If the conditions where all the hits, you will not use Gap lock will only add record locking;
  • If the condition where part or all miss hit will add Gap lock;
• Gap locks will be used in non-unique index or the current index reading does not go in;

Notes: gap is the gap locks, that is, when a table a few lines of operation, in order to prevent phantom read (when I uncommitted transactions, others on the table delete and insert operation), it will be a few hits conditions in row row interval gap Riga locked, others can not be deleted insert operation.

RC, non-blocking reads InnoDB under RR level (snapshot read) how

1, the data line in the DB_TRX_ID (transaction identifier), DB_ROLL_PTR, DB_ROW_ID field;

2, undo log

3、 read view

grammar

group by group

- meet the select clause of column names must be listed as a group or function

- column functions for each group defined in each group by clause returns a result

having

Statistics related to: count, sum, max, min ....

Theoretical paradigm