高频sql面试问题

SQL（结构化查询语言）是一种设计用于检索和 *** 作数据的数据库。它是美国国家标准协会（ANSI）的标准。此语言用于执行选择，更新，删除和插入等数据任务。

表是在具有列和行的模型中设计的数据集合。在表中，指定了列数，称为字段，但未定义行数，称为记录。

数据库是有序形式的一组信息，用于访问，存储和检索数据。

DBMS是一个控制数据维护和使用的程序。它被认为是管理数据的文件管理器。有四种类型的DBMS：

最有用的DBMS是Relational DBMS。它为数据提供了一个关系运算符。

SQL命令分为以下类型：

它包含来自一个或多个表的行和列，可以定义为虚拟表。它消耗的内存较少。

句法：

Join用于从相关的行和列中检索数据。它在两个或多个表之间工作，并且它从两个表返回至少一个匹配。

连接类型是：

数据库查询是数据库表中的数据请求。查询可以是选择查询或任何其他类型的查询。

子查询是查询的一部分。外部查询已知主查询，内部查询识别子查询。始终首先执行子查询，并将结果传递给主查询。

Autoincrement是一个关键字，用于在表中插入新记录时生成数字。

它可用于设置表中数据类型的限制。在创建或更新表语句时，可以使用约束。一些限制是：

SQL中有不同类型的键：

规范化是一种设计技术，它以减少数据依赖性的方式排列表。它将表分成小模块并按关系链接。

非规范化是一种优化方法，我们将多余的数据增加到表中，并在规范化后应用。

存储过程是一组SQL语句，用作访问数据库的函数。为了减少网络流量并提高性能，我们使用存储过程。

句法：

索引用于加速查询的性能。它可以更快地从表中检索数据。可以在一组列上创建索引。

聚簇索引 - 它有助于轻松检索数据，并且只有一个聚簇索引与一个表一起分配。它会更改记录在数据库中的保存方式。

非聚集索引 - 与聚簇索引相比，非聚簇索引很慢。并且在非集群索引的情况下，该表可以具有多个索引。它为表创建一个对象，该表是搜索后指向表的一个点。

触发器 被 用来执行对表中的特定动作，诸如插入，更新或删除 。它是一种 存储过程 。动作和事件是触发器的主要组成部分。执行Action时，事件响应该 *** 作而出现。

通常，这些属性称为ACID。它们有助于数据库事务。

A tomicity -在一个事务中连接两个或更多个单独的数据块，或者所有的块都致力于，或者一个都不。

C onsistency - 事务或者生成新的有效数据状态，或者如果发生任何失望，则在事务启动之前将所有数据返回到其状态。

I solation - 正在进行且尚未提交的事务必须继续与任何其他 *** 作隔离。

D urability -在此 *** 作中，系统保存提交的数据，每当事件发生故障和系统启动后，所有的数据是可用的正确的位置。

SQL语句分为几类：

它被定义为通过为查询提供条件来设置结果集的限制。他们从整个记录中过滤掉一些行。

一些SQL CLAUSES是WHERE和HAVING。

它是一个返回单个值的数学函数。

SQL中的聚合函数是：

为了 *** 作字符串，我们使用String Function。其中一些是：

排序规则 是一 组规则，用于确定数据如何通过比较进行排序 。例如使用一组规则存储的字符数据，这些规则定义了正确字符的序列以及类型，重音和区分大小写。

在系统内存中执行SQL语句时，会创建一个临时工作区，称为Cursor。在select语句中，游标存储了信息。游标可以使用多行，但一次只能处理一行。这组行称为活动集。

游标有两种类型：

SQL服务器是Microsoft关系数据库管理系统（RDBMS）的一种类型或示例。它在IT氛围中提供广泛的事务处理和商业智能。

运算符是一个保留字，主要用于SQL语句的WHERE子句中以进行 *** 作。

空值是没有值的字段。它与Zero不同。假设有一个表，并且在表中有一个字段，可以在不添加值的情况下将记录插入字段，然后该字段将以NULL值保存。

空白是我们提供的价值。

零只是一个数字。

数据仓库被称为来自多个信息源的中央数据中心。这些数据可用于在线处理和挖掘。

在表中，应该只有一个PRIMARY KEY，但在另一种情况下，UNIQUE KEY可以是任意数量的。

PRIMARY KEYS不允许NULL值，但UNIQUE KEY允许NULL值。

数据库基础(面试常见题)

一、数据库基础

1数据抽象：物理抽象、概念抽象、视图级抽象,内模式、模式、外模式

2SQL语言包括数据定义、数据 *** 纵(Data),数据控制(DataControl)

数据定义：CreateTable,AlterTable,DropTable,Craete/DropIndex等

数据 *** 纵：Select,insert,update,delete，数据控制：grant,revoke

3SQL常用命令：

CREATETABLEStudent(

IDNUMBERPRIMARYKEY，NAMEVARCHAR2(50)NOTNULL);//建表

CREATEVIEWview_nameAS

SelectFROMTable_name;//建视图

CreateUNIQUEINDEXindex_nameONTableName(col_name);//建索引

INSERTINTOtablename{column1,column2,}values(exp1,exp2,);//插入

INSERTINTOViewname{column1,column2,}values(exp1,exp2,);//插入视图实际影响表

UPDATEtablenameSETname=’zang3’condition;//更新数据

DELETEFROMTablenameWHEREcondition;//删除

GRANT(Select,delete,)ON(对象)TOUSER_NAME[WITHGRANTOPTION];//授权

REVOKE(权限表)ON(对象)FROMUSER_NAME[WITHREVOKEOPTION]//撤权

列出工作人员及其领导的名字：

SelectENAME,SNAMEFROMEMPLOYEEES

WHEREESUPERName=SName

4视图：

5完整性约束：实体完整性、参照完整性、用户定义完整性

在开始演示之前，我们先介绍下两个概念。

概念一，数据的可选择性基数，也就是常说的cardinality值。

查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步 *** 作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。

那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。

概念二，关于HINT的使用。

这里我来说下HINT是什么，在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。

比如：表t1经过大量的频繁更新 *** 作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？

来看下具体演示

譬如，以下两条SQL，

A：

select from t1 where f1 = 20;

B：

select from t1 where f1 = 30;

如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。

这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。

那回到正题上，MySQL 80 带来了几个HINT，我今天就举个index_merge的例子。

示例表结构：

mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (000 sec)

表记录数：

mysql> select count() from t1;+----------+| count() |+----------+|    32768 |+----------+1 row in set (001 sec)

这里我们两条经典的SQL：

SQL C：

select from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select from t1 where rank1 =100  and rank2 =100  and rank3 =100;

表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然，没有用到任何索引，扫描的行数为32034，cost为324365。

mysql> explain  format=json select from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "324365"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "rows_examined_per_scan": 32034,      "rows_produced_per_join": 115,      "filtered": "036",      "cost_info": {        "read_cost": "323207",        "eval_cost": "1158",        "prefix_cost": "324365",        "data_read_per_join": "49K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们加上hint给相同的查询，再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为44109，明显比之前的快了好几倍。

mysql> explain  format=json select /+ index_merge(t1) / from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "44109"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "union(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1103,      "rows_produced_per_join": 1103,      "filtered": "10000",      "cost_info": {        "read_cost": "33079",        "eval_cost": "11030",        "prefix_cost": "44109",        "data_read_per_join": "473K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们再看下SQL D的计划：

不加HINT，

mysql> explain format=json select from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "53434"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "idx_rank1",      "used_key_parts": [        "rank1"      ],      "key_length": "5",      "ref": [        "const"      ],      "rows_examined_per_scan": 555,      "rows_produced_per_join": 0,      "filtered": "007",      "cost_info": {        "read_cost": "47884",        "eval_cost": "004",        "prefix_cost": "53434",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100))"    }  }}1 row in set, 1 warning (000 sec)

加了HINT，

mysql> explain format=json select /+ index_merge(t1)/ from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "523"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "intersect(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "10000",      "cost_info": {        "read_cost": "513",        "eval_cost": "010",        "prefix_cost": "523",        "data_read_per_join": "440"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100) and (`ytt``t1``rank1` = 100))"    }  }}1 row in set, 1 warning (000 sec)

对比下以上两个，加了HINT的比不加HINT的cost小了100倍。

总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。

以上就是关于高频sql面试问题全部的内容，包括:高频sql面试问题、java面试题中一般数据库会问什么内容(数据库常问的面试题)、面试中常问：mysql数据库做哪些优化也提高mysql性能等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！