One hundred million high concurrent database tuning and best practice rules

Do business, to understand basic SQL statements;

Do performance optimization, to understand the index, understand engine;

Do sub-library sub-table, to understand the master and slave, to understand the separate read and write ...

Use of the database, is to develop basic skills of personnel, the sharper the more in-depth grasp it, the more you can do.

Today we are 10 minutes, comb it again focused on the following aspects:

Summary knowledge database;
database transaction isolation levels and characteristics;
Detailed relational databases, indexes and locking mechanism;
database tuning and best practice;
interview study points and bonus items.

Knowledge Point Summary

 


A different type of database
1
1. The conventional relational database

Oracle: Powerful, the main drawback is that your
MySQL: the Internet industry's most popular database, not just because of the free MySQL. Relational database can be said that the scene features you need, MySQL can be a good meet, will be described in detail later in part explain some MySQL knowledge
MariaDB: MySQL branch is maintained by the open source community, MariaDB though is seen as an alternative to MySQL product, but it extended functionality, have a very good improvement in storage engine
PostgreSQL: also called PGSQL, PGSQL similar to Oracle's multi-process framework that can support high-concurrency scenarios, PG supports almost all SQL standard, the type of support quite rich. PG for more stringent enterprise application scenarios, while MySQL is more suitable for relatively simple business logic, data reliability is low Internet scene.
2.NoSQL database (non-relational database)

Redis: provides the persistence capabilities to support multiple data types. Redis applied to the data and the data size changes quickly predictable scenarios.
MongoDB: a file storage based on distributed database, the data is stored as a document data structure consists of key-value pairs. MongoDB is more suitable table structure is not clear, and the data structures may be changing scenes, not suitable for transactions and complex queries scene.
HBase: built on HDFS, Hadoop is a distributed file system on top of a column-oriented database. Similar to Google's large table design, HBase can provide fast random access to vast amounts of structured data. It consists of rows in the table to sort, a table has a plurality of columns and each column aromatic group can have any number of columns.
HBase HDFS can rely on for reliable storage of massive amounts of data for large volumes of data, write once read many small, does not require complex scene queries.
Cassandra: a highly reliable large-scale distributed storage system. Support distributed structured Key-value storage for high availability as the main target. Suitable write more scenes for doing some simple queries, not suitable for statistical data analysis.
Pika: a persistent mass storage class Redis service,
is compatible with most commands are five main data structures. Pika use disk storage, mainly to solve the cost problem Redis mass storage.
3.NewSQL database (a new generation of relational database)

TiDB: open-source distributed relational database, MySQL is almost fully compatible, able to support the level of elastic expansion, ACID transactions, standard SQL, MySQL syntax and MySQL protocol, with strong consistent data availability features. Both for online transaction processing, but also for online analytical processing.
OceanBase: OceanBase ants gold dress database, OB is a database system to meet the financial level of reliability and data consistency requirements. When you need to use transactions and data than the larger, more suitable for use OB. But the current OB has been commercialized, no longer open source.
Second, the characteristics and the types of things things
1
Detailed knowledge points behind the introduction expands

Third, the paradigm of the database
1
pre-relational database has six paradigms: the first paradigm, the second paradigm, the third paradigm, Bath - Cape Cod Paradigm (BCNF), fourth and fifth paradigm paradigm. The higher the level the more stringent requirements of the paradigm of data tables.

The first paradigm required minimum, only require the table fields are not available in a split.
The second paradigm based on the requirements of each of the first recording paradigm distinguished by unique primary key record all properties are dependent on the primary key.
Third paradigm on the basis of the second paradigm, requires that all properties must rely on direct master key is not allowed indirectly dependent.
In general, the database only to meet the third paradigm on it.

Detailed knowledge of a point: the database transaction
knowledge

▌1. Database transaction characteristics

Characteristics of the database is to investigate the frequency is very high when the interview subject, a total of four characteristics:

Atomicity: refers to a transaction by the sequence of operations atomic composition, all operations either all succeed, or all fail rolled back.
Consistency: refers to the execution of a transaction can not undermine the integrity and consistency of data in the database, and then execute a transaction, the database must impose a consistent state before the execution. For example, when doing multi-table operation, or multiple tables are new value after the transaction, either all the old value before the transaction.
Isolation: refers to a plurality of users concurrent access to the database, each database transaction performed by the user, not being disturbed by operation of other matters, to isolation between a plurality of concurrent transactions. Transaction isolation level us later.
Persistence: is that once a transaction commit and execute successfully, then the changes to the data in the database is permanent, even in the case of a database system experienced a failure of the operation will not be lost to commit the transaction.
▌2. Things concurrency issues with isolation level

 

a. transaction concurrency issues

Dirty read: dirty read transaction refers to a process where the data is read in another uncommitted transaction, e.g., to account A transfer element B500, increase the balance of B, but not yet committed the transaction is completed, if another case the request is to obtain an increase in the balance of B, which happened dirty read, because if it fails to roll back the transaction, the balance of B should not be increased.
Non-repeatable read: non-repeatable read refers to a database data within a transaction scope times query returns a different data values, which is due between multiple queries, there are other matters to modify the data and submit the .
Magic Reading: is the same query twice to execute a transaction, the second query result set returned with the first query is not the same. The difference is that non-repeatable read, non-repeatable read record is the same, different values of the two reads. The phantom read or delete a record increase, resulting in different results of the same conditions twice the number of records retrieved.
b: four isolation level of the transaction

It can be used to solve these types of concurrency problems. FIG right, 4 from top to bottom isolation levels from low to high.

级别1读未提交:也就是可以读取到其他事务未提交的内容,这是最低的隔离级别,这个隔离级别下,前面提到的三种并发问题都有可能发生。
级别2读已提交:就是只能读取到其他事务已经提交的数据。这个隔离级别可以解决脏读问题。
级别三可重复读:可以保证整个事务过程中,对同数据的多次读取结果是相同的。这个级别可以解决脏读和不可重复读的问题。MySQL默认的隔离级别就是可重复读。
级别四串行化:这是最高的隔离级别,所有事务操作都依次顺序执行。这个级别会导致并发度下降,性能最差。不过这个级别可以解决前面提到的所有并发问题。
▌3.事务分类

共分5大类:

 

扁平化事务:在扁平事务中,所有的操作都在同一层次,这也是我们平时使用最多的一种事务。它的主要限制是不能提交或者回滚事务的某一部分,要么都成功,要么都回滚。
带保存点的扁平事务:为了解决第一种事务的弊端,就有了第二种带保存点的扁平事务。它允许事务在执行过程中回滚到较早的状态,而不是全部回滚。通过在事务中插入保存点,当操作失败后,可以选择回滚到最近的保存点处。
链事务:可以看做是第二种事务的变种。它在事务提交时,会将必要的上下文隐式传递给下一个事务,当事务失败时就可以回滚到最近的事务。不过,链事务只能回滚到最近的保存点,而带保存点的扁平化事务是可以回滚到任意的保存点。
嵌套事务:由顶层事务和子事务构成,类似于树的结构。一般顶层事务负责逻辑管理,子事务负责具体的工作,子事务可以提交,但真正提交要等到父事务提交,如果上层事务回滚,那么所有的子事务都会回滚。
分布式事务:是指分布式环境中的扁平化事务。
其中,常用的分布式事务解决方案共4种

a.XA协议:是保证强一致性的刚性事务。实现方式有两段式提交和三段式提交。两段式提交需要有一个事务协调者来保证所有的事务参与者都完成了第一阶段的准备工作。如果协调者收到所有参与者都准备好的消息,就会通知所有的事务执行第二阶段提交。一般场景下两段式提交已经能够很好得解决分布式事务了,然而两阶段在即使只有一个进程发生故障时,也会导致整个系统存在较长时间的阻塞。三段式提交通过增加Pre-commit阶段来减少前面提到的系统阻塞的时间。三段式提交很少在实际中使用,简单了解就可以了。

b.TCC:是满足最终一致性的柔性事务方案。TCC采用补偿机制,核心思想是对每个操作,都要注册对应的确认和补偿操作。它分为三个阶段:Try阶段主要对业务系统进行检测及资源预留;Confirm阶段对业务系统做确认提交。Cancel阶段是在业务执行错误,执行回滚,释放预留的资源。

c.消息事务:第三种方案是消息一致性方案。基本思路是将本地操作和发送消息放在一个事务中,保证本地操作和消息发送要么都成功要么都失败。下游应用订阅消息,收到消息后执行对应操作。

d.GTS/Fescar:阿里云中的全局事务服务GTS,对应的开源版本是Fescar。Fescar基于两段式提交进行改良,剥离了分布式事务方案对数据库在协议支持上的要求。使用Fescar的前提是分支事务中涉及的资源,必须是支持ACID事务的关系型数据库。分支的提交和回滚机制,都依赖于本地事务来保障。 Fescar的实现目前还存在一些局限,比如事务隔离级别最高支持到读已提交级别。

详解知识点二:MySQL数据库

 


▌1.常用SQL语句

需要能手写常用SQL语句,这里没有什么特殊的技巧,根据如图列出的语句类型多做一些练习

▌2.数据类型

要知道MySQL都提供哪些基本都数据类型,不同数据类型占用的空间大小。

▌3.MySQL中主要的存储引擎

MyISAM是MySQL官方提供的存储引擎,其特点是支持全文索引,查询效率比较高,缺点是不支持事务、使用表级锁。InnoDB在5.5版本后成为了Mysql的默认存储引擎,特点是支持ACID事务、支持外键、支持行级锁提高了并发效率。TokuDB是第三方开发的开源存储引擎,有非常快的写速度,支持数据的压缩存储、可以在线添加索引而不影响读写操作。但是因为压缩的原因,TokuDB非常适合访问频率不高的数据或历史数据归档,不适合大量读取的场景。

▌4.MySQL中的锁

MyIASAM使用表级锁,InnoDB使用行级锁。表锁开销小,加锁快,不会出现死锁;但是锁的粒度大,发生锁冲突的概率高,并发访问效率比较低。行级锁开销大,加锁慢,有可能会出现死锁,不过因为锁定粒度最小,发生锁冲突的概率低,并发访问效率比较高。

注:

共享锁也就是读锁,其他事务可以读,但不能写。MySQL可以通过Lock In Share Mode语句显示使用共享锁。

排他锁就是写锁,其他事务不能读取,也不能写。对于Update、Delete和INSERT语句,InnoDB会自动给涉及的数据集加排他锁,或者使用select for update显示使用排他锁。

▌5.索引

后文重点讲解

▌6.MySQL的存储过程与函数

存储过程和函数都可以避免开发人员重复编写相同的SQL语句,并且存储过程和函数都是在MySQL服务器中执行的,可以减少客户端和服务器端的数据传输。

存储过程能够实现更复杂的功能,而函数一般用来实现针对性比较强的功能,例如特殊策略求和等。存储过程可以执行包括修改表等一系列数据库操作,而用户定义函数不能用于执行修改全局数据库状态的操作。

存储过程一般是作为一个独立的部分来执行,而函数可以作为查询语句的一个部分来调用。SQL语句中不能使用存储过程,但可以使用函数。

不过存储过程一般与数据库实现绑定,使用存储过程会降低程序的可移植性,应谨慎使用。

▌7.新特性

可以了解MySQL8.0的一些新特性,例如默认字符集格式改为了UTF8;增加了隐藏索引的功能,隐藏后的索引不会被查询优化器使用,可以使用这个特性用于性能调试;支持了通用表表达式,使复杂查询中的嵌入表语句更加清晰;新增了窗口函数的概念,它可以用来实现新的查询方式。窗口函数与 SUM、COUNT等集合函数类似,但不会将多行查询结果合并,而是将结果放在多行中。即窗口函数不需要GROUP BY。

▌8.MySQL调优

后文重点讲解。

 

➔重点讲解一:MySQL索引
1


索引可以大幅增加数据库的查询的性能,在实际业务场景中,或多或少都会使用到。

但是索引是有如下2个代价的:

a.需要额外的磁盘空间来保存索引

b.对于插入、更新、删除等操作由于更新索引会增加额外的开销

因此索引比较适合用在读多写少的场景。

▌1.MySQL索引类型

如左面的模块,共分为5类:

唯一索引:就是索引列中的值必须是唯一的,但是允许出现空值。这种索引一般用来保证数据的唯一性,比如保存账户信息的表,每个账户的id必须保证唯一,如果重复插入相同的账户id时会MySQL返回异常。
主键索引:是一种特殊的唯一索引,但是它不允许出现空值。
普通索引:与唯一索引不同,它允许索引列中存在相同的值。例如学生的成绩表,各个学科的分数是允许重复的,就可以使用普通索引。
联合索引:就是由多个列共同组成的索引。一个表中含有多个单列的索引并不是联合索引,联合索引是对多个列字段按顺序共同组成一个索引。应用联合索引时需要注意最左原则,就是Where查询条件中的字段必须与索引字段从左到右进行匹配。比如,一个用户信息表,用姓名和年龄组成了联合索引,如果查询条件是姓名等于张三,那么满足最左原则;如果查询条件是年龄大于20,由于索引中最左的字段是姓名不是年龄,所以不能使用这个索引。
全文索引:前面提到了,MyISAM引擎中实现了这个索引,在5.6版本后InnoDB引擎也支持了全文索引,并且在5.7.6版本后支持了中文索引。全文索引只能在CHAR,VARCHAR,TEXT类型字段上使用,底层使用倒排索引实现。要注意对于大数据量的表,生成全文索引会非常消耗时间也非常消耗磁盘空间。
▌2.索引实现

如右面的模块,索引实现共分4种形式:

B+树实现:b+树比较适合用作’>‘或’<'这样的范围查询,是MySQL中最常使用的一种索引实现。

R-tree:是一种用于处理多维数据的数据结构,可以对地理数据进行空间索引。不过实际业务场景中使用的比较少。

Hash:是使用散列表来对数据进行索引,Hash方式不像Btree那样需要多次查询才能定位到记录,因此Hash索引的效率高于B-tree,但是不支持范围查找和排序等功能.实际使用的也比较少。

FullText:就是我们前面提到的全文索引,是一种记录关键字与对应文档关系的倒排索引。

➔重点讲解二:MySQL调优
1

 


MySQL的调优也是研发人员需要掌握的一项技能

一般MySQL调优有图中的4个纬度:

针对数据库设计、表结构设计以及索引设置纬度进行的优化;

对业务中使用的SQL语句进行优化,例如调整Where查询条件;

对mysql服务的配置进行优化,例如对链接数的管理,对索引缓存、查询缓存、排序缓存等各种缓存大小进行优化;

对硬件设备和操作系统设置进行优化,例如调整操作系统参数、禁用Swap、增加内存、升级固态硬盘等等。

这四个纬度从优化的成本角度来讲,从左到右优化成本逐渐升高;从优化效果角度来看,从右到左优化的效果更高。

对于研发人员来说,前两个纬度与业务息息相关,因此需要重点掌握,后两个纬度更适合DBA进行深入学习,简单了解就好。

本文将重点关注前两个纬度

▌1.表结构和索引的优化

 

 

如左面的模块,应该掌握如下6个原则:

第1个原则:要在设计表结构时,考虑数据库的水平与垂直扩展能力,提前规划好未来1年的数据量、读写量的增长,规划好分库分表方案。比如设计用户信息表,预计1年后用户数据10亿条,写QPS约5000,读QPS30000,可以设计按UID纬度进行散列,分为4个库每个库32张表,单表数据量控制在KW级别;

第2个原则:要为字段选择合适的数据类型,在保留扩展能力的前提下,优先选用较小的数据结构。例如保存年龄的字段,要使用TINYINT而不要使用INT;

第3个原则:可以将字段多的表分解成多个表,必要时增加中间表进行关联。假如一张表有4、50个字段显然不是一个好的设计;

第4个原则:是设计关系数据库时需要满足第三范式,但为了满足第三范式,我们可能会拆分出多张表。而在进行查询时需要对多张表进行关联查询,有时为了提高查询效率,会降低范式的要求,在表中保存一定的冗余信息,也叫做反范式。但要注意反范式一定要适度;

第5个原则:要擅用索引,比如为经常作为查询条件的字段创建索引、创建联合索引时要根据最左原则考虑索引的复用能力,不要重复创建索引;要为保证数据不能重复的字段创建唯一索引等等。不过要注意索引对插入、更新等写操作是有代价的,不要滥用索引。比如像性别这样唯一很差的字段就不适合建立索引;

第6个原则:列字段尽量设置为Not Null,MySQL难以对使用Null的列进行查询优化,允许Null会使索引、索引统计和值更加复杂。允许Null值的列需要更多的存储空间,还需要MySQL内部进行特殊处理。

▌2.SQL语句进行优化的原则

如右面的模块,共分5个原则:

第1个原则:要找的最需要优化的SQL语句。要么是使用最频繁的语句,要么是优化后提高最明显的语句,可以通过查询MySQL的慢查询日志来发现需要进行优化的SQL语句;
第2个原则:要学会利用MySQL提供的分析工具。例如使用Explain来分析语句的执行计划,看看是否使用了索引,使用了哪个索引,扫描了多少记录,是否使用文件排序等等。或者利用Profile命令来分析某个语句执行过程中各个分步的耗时;
第3个原则:要注意使用查询语句是要避免使用Select
*,而是应该指定具体需要获取的字段。原因一是可以避免查询出不需要使用的字段,二是可以避免查询列字段的元信息;
第4个原则:是尽量使用Prepared Statements,一个是性能更好,另一个是可以防止SQL注入;
第5个原则:是尽量使用索引扫描来进行排序,也就是尽量在有索引的字段上进行排序操作。
以上为数据库操作须掌握的内容,可以进行差缺补漏,希望对研发人员有一定的帮助

面试考察点
1.必须了解数据库的基本原理、使用场景以及常用队列、数据库的特点。MySQL提供了多种引擎可以支持事务型与非事务型的关系对象库服务等等。

2.要深刻理解数据库事务的ACID特性,了解并发事务可能导致的并发问题和不同的数据库隔离级别如何解决这些并发问题。

3.要掌握常用的MySQL语句,比如WHERE条件查询语句、JOIN关联语句、ORDER BY排序语句等等。还要熟悉常用的自带函数,例如SUM、COUNT等等。

4.要了解MySQL数据库不同引擎的特点及不同类型的索引实现。比如最长使用的InnoDB非常擅长事务处理,MyISAM比较适合非事务的简单查询场景。比如知道MySQL的唯一索引、联合索引、全文索引等不同索引类型,以及最长使用等B+树索引实现等等。

面试加分项
1.要了解新特性,例如MySQL8.0中提供了窗口函数来支持新的查询方式;支持通用表表达式,使复杂查询中的嵌入表语句更加清晰等等。

2.要知道数据库表设计原则,如果有过线上业务数据库的设计经验就更好了,你能够知道如何对容量进行评估,也知道适当分库分表来保证未来服务的可扩展性,这会对面试起到积极的影响。

3.最好有过数据库调优经验,例如明明建立了索引的语句,但是查询效率还是很慢,通过Explain分析发现表中有多个索引,MySQL的优化器选用了错误的索引,导致查询效率偏低,然后通过在SQL语句中使用Use
Index来指定索引解决。

以上内容摘取自《32个Java面试必考点》 第09讲(下):MySQL调优与最佳实践
主讲人:新浪微博技术专家 张雷,点此了解更多

Guess you like

Origin www.cnblogs.com/ygunoil/p/10981110.html