一次搞定各种数据库SQL执行计划|原力计划

作者：命运2502901041_350 | 来源：互联网 | 2023-07-20 13:55

作者|董旭阳TonyDong出品|CSDN博客执行计划（executionplan，也叫查询计划或者解释计划）是数据库执行SQL语句的具体

作者 | 董旭阳TonyDong

出品 | CSDN 博客

执行计划&＃xff08;execution plan&＃xff0c;也叫查询计划或者解释计划&＃xff09;是数据库执行 SQL 语句的具体步骤&＃xff0c;例如通过索引还是全表扫描访问表中的数据&＃xff0c;连接查询的实现方式和连接的顺序等。如果 SQL 语句性能不够理想&＃xff0c;我们首先应该查看它的执行计划。本文主要介绍如何在各种数据库中获取和理解执行计划&＃xff0c;并给出进一步深入分析的参考文档。

现在许多管理和开发工具都提供了查看图形化执行计划的功能&＃xff0c;例如 MySQL Workbench、Oracle SQL Developer、SQL Server Management Studio、DBeaver 等&＃xff1b;不过我们不打算使用这类工具&＃xff0c;而是介绍利用数据库提供的命令查看执行计划。

我们先给出在各种数据库中查看执行计划的一个简单汇总&＃xff1a;

本文使用的示例表和数据可以点击链接《SQL 入门教程》示例数据库&＃xff08;https://tonydong.blog.csdn.net/article/details/86518676&＃xff09;。

MySQL 执行计划

MySQL 中获取执行计划的方法很简单&＃xff0c;就是在 SQL 语句的前面加上EXPLAIN关键字&＃xff1a;

EXPLAIN SELECT e.first_name,e.last_name,e.salary,d.department_nameFROM employees eJOIN departments d ON (e.department_id &＃61; d.department_id)WHERE e.salary > 15000;

执行该语句将会返回一个表格形式的执行计划&＃xff0c;包含了 12 列信息&＃xff1a;

id|select_type|table|partitions|type |possible_keys |key |key_len|ref |rows|filtered|Extra | --|-----------|-----|----------|------|-----------------|-------|-------|--------------------|----|--------|-----------|1|SIMPLE |e | |ALL |emp_department_ix| | | | 107| 33.33|Using where|1|SIMPLE |d | |eq_ref|PRIMARY |PRIMARY|4 |hrdb.e.department_id| 1| 100| |

MySQL 中的EXPLAIN支持 SELECT、DELETE、INSERT、REPLACE 以及 UPDATE 语句。

接下来&＃xff0c;我们要做的就是理解执行计划中这些字段的含义。下表列出了 MySQL 执行计划中的各个字段的作用&＃xff1a;

对于上面的示例&＃xff0c;只有一个 SELECT 子句&＃xff0c;id 都为 1&＃xff1b;首先对 employees 表执行全表扫描&＃xff08;type &＃61; ALL&＃xff09;&＃xff0c;处理了 107 行数据&＃xff0c;使用 WHERE 条件过滤后预计剩下 33.33% 的数据&＃xff08;估计不准确&＃xff09;&＃xff1b;然后针对这些数据&＃xff0c;依次使用 departments 表的主键&＃xff08;key &＃61; PRIMARY&＃xff09;查找一行匹配的数据&＃xff08;type &＃61; eq_ref、rows &＃61; 1&＃xff09;。

使用 MySQL 8.0 新增的 ANALYZE 选项可以显示实际执行时间等额外的信息&＃xff1a;

EXPLAIN ANALYZE SELECT e.first_name,e.last_name,e.salary,d.department_nameFROM employees eJOIN departments d ON (e.department_id &＃61; d.department_id)WHERE e.salary > 15000; -> Nested loop inner join (cost&＃61;23.43 rows&＃61;36) (actual time&＃61;0.325..1.287 rows&＃61;3 loops&＃61;1)-> Filter: ((e.salary > 15000.00) and (e.department_id is not null)) (cost&＃61;10.95 rows&＃61;36) (actual time&＃61;0.281..1.194 rows&＃61;3 loops&＃61;1)-> Table scan on e (cost&＃61;10.95 rows&＃61;107) (actual time&＃61;0.266..0.716 rows&＃61;107 loops&＃61;1)-> Single-row index lookup on d using PRIMARY (department_id&＃61;e.department_id) (cost&＃61;0.25 rows&＃61;1) (actual time&＃61;0.013..0.015 rows&＃61;1 loops&＃61;3)

其中&＃xff0c;Nested loop inner join 表示使用嵌套循环连接的方式连接两个表&＃xff0c;employees 为驱动表。cost 表示估算的代价&＃xff0c;rows 表示估计返回的行数&＃xff1b;actual time 显示了返回第一行和所有数据行花费的实际时间&＃xff0c;后面的 rows 表示迭代器返回的行数&＃xff0c;loops 表示迭代器循环的次数。

关于 MySQL EXPLAIN 命令的使用和参数&＃xff0c;可以参考 MySQL 官方文档 EXPLAIN 语句&＃xff08;https://dev.mysql.com/doc/refman/8.0/en/explain.html&＃xff09;。

关于 MySQL 执行计划的输出信息&＃xff0c;可以参考 MySQL 官方文档理解查询执行计划&＃xff08;https://dev.mysql.com/doc/refman/8.0/en/execution-plan-information.html&＃xff09;。

Oracle 执行计划

Oracle 中提供了多种查看执行计划的方法&＃xff0c;本文使用以下方式&＃xff1a;

使用EXPLAIN PLAN FOR命令生成并保存执行计划&＃xff1b;
显示保存的执行计划。

首先&＃xff0c;生成执行计划&＃xff1a;

EXPLAIN PLAN FOR SELECT e.first_name,e.last_name,e.salary,d.department_nameFROM employees eJOIN departments d ON (e.department_id &＃61; d.department_id)WHERE e.salary > 15000;

EXPLAIN PLAN FOR命令不会运行 SQL 语句&＃xff0c;因此创建的执行计划不一定与执行该语句时的实际计划相同。

该命令会将生成的执行计划保存到全局的临时表 PLAN_TABLE 中&＃xff0c;然后使用系统包 DBMS_XPLAN 中的存储过程格式化显示该表中的执行计划。以下语句可以查看当前会话中的最后一个执行计划&＃xff1a;

SELECT * FROM TABLE(DBMS_XPLAN.display); PLAN_TABLE_OUTPUT | --------------------------------------------------------------------------------------------| Plan hash value: 1343509718 || --------------------------------------------------------------------------------------------| | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time || --------------------------------------------------------------------------------------------| | 0 | SELECT STATEMENT | | 44 | 1672 | 6 (17)| 00:00:01 || | 1 | MERGE JOIN | | 44 | 1672 | 6 (17)| 00:00:01 || | 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0)| 00:00:01 || | 3 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0)| 00:00:01 || |* 4 | SORT JOIN | | 44 | 968 | 4 (25)| 00:00:01 || |* 5 | TABLE ACCESS FULL | EMPLOYEES | 44 | 968 | 3 (0)| 00:00:01 || --------------------------------------------------------------------------------------------|| Predicate Information (identified by operation id): | --------------------------------------------------- ||4 - access("E"."DEPARTMENT_ID"&＃61;"D"."DEPARTMENT_ID") |filter("E"."DEPARTMENT_ID"&＃61;"D"."DEPARTMENT_ID") |5 - filter("E"."SALARY">15000) |

Oracle 中的EXPLAIN PLAN FOR支持 SELECT、UPDATE、INSERT 以及 DELETE 语句。

接下来&＃xff0c;我们同样需要理解执行计划中各种信息的含义&＃xff1a;

Plan hash value 是该语句的哈希值。SQL 语句和执行计划会存储在库缓存中&＃xff0c;哈希值相同的语句可以重用已有的执行计划&＃xff0c;也就是软解析&＃xff1b;
Id 是一个序号&＃xff0c;但不代表执行的顺序。执行的顺序按照缩进来判断&＃xff0c;缩进越多的越先执行&＃xff0c;同样缩进的从上至下执行。Id 前面的星号表示使用了谓词判断&＃xff0c;参考下面的 Predicate Information&＃xff1b;
Operation 表示当前的操作&＃xff0c;也就是如何访问表的数据、如何实现表的连接、如何进行排序操作等&＃xff1b;
Name 显示了访问的表名、索引名或者子查询等&＃xff0c;前提是当前操作涉及到了这些对象&＃xff1b;
Rows 是 Oracle 估计的当前操作返回的行数&＃xff0c;也叫基数&＃xff08;Cardinality&＃xff09;&＃xff1b;
Bytes 是 Oracle 估计的当前操作涉及的数据量
Cost (%CPU) 是 Oracle 计算执行该操作所需的代价&＃xff1b;
Time 是 Oracle 估计执行该操作所需的时间&＃xff1b;
Predicate Information 显示与 Id 相关的谓词信息。access 是访问条件&＃xff0c;影响到数据的访问方式&＃xff08;扫描表还是通过索引&＃xff09;&＃xff1b;filter 是过滤条件&＃xff0c;获取数据后根据该条件进行过滤。

在上面的示例中&＃xff0c;Id 的执行顺序依次为 3 -> 2 -> 5 -> 4- >1。首先&＃xff0c;Id &＃61; 3 扫描主键索引 DEPT_ID_PK&＃xff0c;Id &＃61; 2 按主键 ROWID 访问表 DEPARTMENTS&＃xff0c;结果已经排序&＃xff1b;其次&＃xff0c;Id &＃61; 5 全表扫描访问 EMPLOYEES 并且利用 filter 过滤数据&＃xff0c;Id &＃61; 4 基于部门编号进行排序和过滤&＃xff1b;最后 Id &＃61; 1 执行合并连接。显然&＃xff0c;此处 Oracle 选择了排序合并连接的方式实现两个表的连接。

关于 Oracle 执行计划和 SQL 调优&＃xff0c;可以参考 Oracle 官方文档《SQL Tuning Guide》&＃xff08;https://docs.oracle.com/en/database/oracle/oracle-database/19/tgsql/&＃xff09;。

SQL Server 执行计划

SQL Server Management Studio 提供了查看图形化执行计划的简单方法&＃xff0c;这里我们介绍一种通过命令查看的方法&＃xff1a;

SET STATISTICS PROFILE ON

以上命令可以打开 SQL Server 语句的分析功能&＃xff0c;打开之后执行的语句会额外返回相应的执行计划&＃xff1a;

SELECT e.first_name,e.last_name,e.salary,d.department_nameFROM employees eJOIN departments d ON (e.department_id &＃61; d.department_id)WHERE e.salary > 15000;first_name|last_name|salary |department_name| ----------|---------|--------|---------------| Steven |King |24000.00|Executive | Neena |Kochhar |17000.00|Executive | Lex |De Haan |17000.00|Executive |Rows|Executes|StmtText |StmtId|NodeId|Parent|PhysicalOp |LogicalOp |Argument |DefinedValues |EstimateRows|EstimateIO |EstimateCPU|AvgRowSize|TotalSubtreeCost|OutputList |Warnings|Type |Parallel|EstimateExecutions| ----|--------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------|------|--------------------|--------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------|------------|------------|-----------|----------|----------------|----------------------------------------------------------------------|--------|--------|--------|------------------|3| 1|SELECT e.first_name,e.last_name,e.salary,d.department_name¶ FROM employees e¶ JOIN departments d ON (e.department_id &＃61; d.department_id)¶ WHERE e.salary > 15000 | 1| 1| 0| | | | | 2.9719627| | | | 0.007803641| | |SELECT | 0| |3| 1| |--Nested Loops(Inner Join, OUTER REFERENCES:([e].[department_id])) | 1| 2| 1|Nested Loops |Inner Join |OUTER REFERENCES:([e].[department_id]) | | 2.9719627| 0| 0| 57| 0.007803641|[e].[first_name], [e].[last_name], [e].[salary], [d].[department_name]| |PLAN_ROW| 0| 1|3| 1| |--Clustered Index Scan(OBJECT:([hrdb].[dbo].[employees].[emp_emp_id_pk] AS [e]), WHERE:([hrdb].[dbo].[employees].[salary] as [e].[salary]>(15000.00))) | 1| 3| 2|Clustered Index Scan|Clustered Index Scan|OBJECT:([hrdb].[dbo].[employees].[emp_emp_id_pk] AS [e]), WHERE:([hrdb].[dbo].[employees].[salary] as [e].[salary]>(15000.00)) |[e].[first_name], [e].[last_name], [e].[salary], [e].[department_id]| 3|0.0038657407| 2.747E-4| 44| 0.004140441|[e].[first_name], [e].[last_name], [e].[salary], [e].[department_id] | |PLAN_ROW| 0| 1|3| 3| |--Clustered Index Seek(OBJECT:([hrdb].[dbo].[departments].[dept_id_pk] AS [d]), SEEK:([d].[department_id]&＃61;[hrdb].[dbo].[employees].[department_id] as [e].[department_id]) ORDERED FORWARD)| 1| 4| 2|Clustered Index Seek|Clustered Index Seek|OBJECT:([hrdb].[dbo].[departments].[dept_id_pk] AS [d]), SEEK:([d].[department_id]&＃61;[hrdb].[dbo].[employees].[department_id] as [e].[department_id]) ORDERED FORWARD|[d].[department_name] | 1| 0.003125| 1.581E-4| 26| 0.0035993|[d].[department_name] | |PLAN_ROW| 0| 3|

SQL Server 中的执行计划支持 SELECT、INSERT、UPDATE、DELETE 以及 EXECUTE 语句。

SQL Server 执行计划各个步骤的执行顺序按照缩进来判断&＃xff0c;缩进越多的越先执行&＃xff0c;同样缩进的从上至下执行。接下来&＃xff0c;我们需要理解执行计划中各种信息的含义&＃xff1a;

Rows 表示该步骤实际产生的记录数&＃xff1b;
Executes 表示该步骤实际被执行的次数&＃xff1b;
StmtText 包含了每个步骤的具体描述&＃xff0c;也就是如何访问和过滤表的数据、如何实现表的连接、如何进行排序操作等&＃xff1b;
StmtId&＃xff0c;该语句的编号&＃xff1b;
NodeId&＃xff0c;当前操作步骤的节点号&＃xff0c;不代表执行顺序&＃xff1b;
Parent&＃xff0c;当前操作步骤的父节点&＃xff0c;先执行子节点&＃xff0c;再执行父节点&＃xff1b;
PhysicalOp&＃xff0c;物理操作&＃xff0c;例如连接操作的嵌套循环实现&＃xff1b;
LogicalOp&＃xff0c;逻辑操作&＃xff0c;例如内连接操作&＃xff1b;
Argument&＃xff0c;操作使用的参数&＃xff1b;
DefinedValues&＃xff0c;定义的变量值&＃xff1b;
EstimateRows&＃xff0c;估计返回的行数&＃xff1b;
EstimateIO&＃xff0c;估计的 IO 成本&＃xff1b;
EstimateCPU&＃xff0c;估计的 CPU 成本&＃xff1b;
AvgRowSize&＃xff0c;平均返回的行大小&＃xff1b;
TotalSubtreeCost&＃xff0c;当前节点累计的成本&＃xff1b;
OutputList&＃xff0c;当前节点输出的字段列表&＃xff1b;
Warnings&＃xff0c;预估得到的警告信息&＃xff1b;
Type&＃xff0c;当前操作步骤的类型&＃xff1b;
Parallel&＃xff0c;是否并行执行&＃xff1b;
EstimateExecutions&＃xff0c;该步骤预计被执行的次数&＃xff1b;

对于上面的语句&＃xff0c;节点执行的顺序为 3 -> 4 -> 2 -> 1。首先执行第 3 行&＃xff0c;通过聚集索引&＃xff08;主键&＃xff09;扫描 employees 表加过滤的方式返回了 3 行数据&＃xff0c;估计的行数&＃xff08;3.0841121673583984&＃xff09;与此非常接近&＃xff1b;然后执行第 4 行&＃xff0c;循环使用聚集索引的方式查找 departments 表&＃xff0c;循环 3 次每次返回 1 行数据&＃xff1b;第 2 行是它们的父节点&＃xff0c;表示使用 Nested Loops 方式实现 Inner Join&＃xff0c;Argument 列&＃xff08;OUTER REFERENCES:([e].[department_id])&＃xff09;说明驱动表为 employees &＃xff1b;第 1 行代表了整个查询&＃xff0c;不执行实际操作。

最后&＃xff0c;可以使用以下命令关闭语句的分析功能&＃xff1a;

SET STATISTICS PROFILE OFF

关于 SQL Server 执行计划和 SQL 调优&＃xff0c;可以参考 SQL Server 官方文档执行计划。

PostgreSQL 执行计划

PostgreSQL 中获取执行计划的方法与 MySQL 类似&＃xff0c;也就是在 SQL 语句的前面加上EXPLAIN关键字&＃xff1a;

EXPLAIN SELECT e.first_name,e.last_name,e.salary,d.department_nameFROM employees eJOIN departments d ON (e.department_id &＃61; d.department_id)WHERE e.salary > 15000;QUERY PLAN | ----------------------------------------------------------------------| Hash Join (cost&＃61;3.38..4.84 rows&＃61;3 width&＃61;29) |Hash Cond: (d.department_id &＃61; e.department_id) |-> Seq Scan on departments d (cost&＃61;0.00..1.27 rows&＃61;27 width&＃61;15) |-> Hash (cost&＃61;3.34..3.34 rows&＃61;3 width&＃61;22) |-> Seq Scan on employees e (cost&＃61;0.00..3.34 rows&＃61;3 width&＃61;22)|Filter: (salary > &＃39;15000&＃39;::numeric) |

PostgreSQL 中的EXPLAIN支持 SELECT、INSERT、UPDATE、DELETE、VALUES、EXECUTE、DECLARE、CREATE TABLE AS 以及 CREATE MATERIALIZED VIEW AS 语句。

PostgreSQL 执行计划的顺序按照缩进来判断&＃xff0c;缩进越多的越先执行&＃xff0c;同样缩进的从上至下执行。对于以上示例&＃xff0c;首先对 employees 表执行全表扫描&＃xff08;Seq Scan&＃xff09;&＃xff0c;使用 salary > 15000 作为过滤条件&＃xff1b;cost 分别显示了预估的返回第一行的成本&＃xff08;0.00&＃xff09;和返回所有行的成本&＃xff08;3.34&＃xff09;&＃xff1b;rows 表示预估返回的行数&＃xff1b;width 表示预估返回行的大小&＃xff08;单位 Byte&＃xff09;。然后将扫描结果放入到内存哈希表中&＃xff0c;两个 cost 都等于 3.34&＃xff0c;因为是在扫描完所有数据后一次性计算并存入哈希表。接下来扫描 departments 并且根据 department_id 计算哈希值&＃xff0c;然后和前面的哈希表进行匹配&＃xff08;d.department_id &＃61; e.department_id&＃xff09;。最上面的一行表明数据库采用的是 Hash Join 实现连接操作。

PostgreSQL 中的EXPLAIN也可以使用 ANALYZE 选项显示语句的实际运行时间和更多信息&＃xff1a;

EXPLAIN ANALYZE SELECT e.first_name,e.last_name,e.salary,d.department_nameFROM employees eJOIN departments d ON (e.department_id &＃61; d.department_id)WHERE e.salary > 15000;QUERY PLAN | ----------------------------------------------------------------------------------------------------------------| Hash Join (cost&＃61;3.38..4.84 rows&＃61;3 width&＃61;29) (actual time&＃61;0.347..0.382 rows&＃61;3 loops&＃61;1) |Hash Cond: (d.department_id &＃61; e.department_id) |-> Seq Scan on departments d (cost&＃61;0.00..1.27 rows&＃61;27 width&＃61;15) (actual time&＃61;0.020..0.037 rows&＃61;27 loops&＃61;1) |-> Hash (cost&＃61;3.34..3.34 rows&＃61;3 width&＃61;22) (actual time&＃61;0.291..0.292 rows&＃61;3 loops&＃61;1) |Buckets: 1024 Batches: 1 Memory Usage: 9kB |-> Seq Scan on employees e (cost&＃61;0.00..3.34 rows&＃61;3 width&＃61;22) (actual time&＃61;0.034..0.280 rows&＃61;3 loops&＃61;1)|Filter: (salary > &＃39;15000&＃39;::numeric) |Rows Removed by Filter: 104 | Planning Time: 1.053 ms | Execution Time: 0.553 ms |

EXPLAIN ANALYZE通过执行语句获得了更多的信息。其中&＃xff0c;actual time 是每次迭代实际花费的平均时间&＃xff08;ms&＃xff09;&＃xff0c;也分为启动时间和完成时间&＃xff1b;loops 表示迭代次数&＃xff1b;Hash 操作还会显示桶数&＃xff08;Buckets&＃xff09;、分批数量&＃xff08;Batches&＃xff09;以及占用的内存&＃xff08;Memory Usage&＃xff09;&＃xff0c;Batches 大于 1 意味着需要使用到磁盘的临时存储&＃xff1b;Planning Time 是生成执行计划的时间&＃xff1b;Execution Time 是执行语句的实际时间&＃xff0c;不包括 Planning Time。

关于 PostgreSQL 的执行计划和性能优化&＃xff0c;可以参考 PostgreSQL 官方文档性能提示&＃xff08;https://www.postgresql.org/docs/12/performance-tips.html&＃xff09;。

SQLite 执行计划

SQLite 也提供了EXPLAIN QUERY PLAN命令&＃xff0c;用于获取 SQL 语句的执行计划&＃xff1a;

sqlite> EXPLAIN QUERY PLAN...> SELECT e.first_name,e.last_name,e.salary,d.department_name...> FROM employees e...> JOIN departments d ON (e.department_id &＃61; d.department_id)...> WHERE e.salary > 15000; QUERY PLAN |--SCAN TABLE employees AS e &＃96;--SEARCH TABLE departments AS d USING INTEGER PRIMARY KEY (rowid&＃61;?)

SQLite 中的EXPLAIN QUERY PLAN支持 SELECT、INSERT、UPDATE、DELETE 等语句。

SQLite 执行计划同样按照缩进来显示&＃xff0c;缩进越多的越先执行&＃xff0c;同样缩进的从上至下执行。以上示例先扫描 employees 表&＃xff0c;然后针对该结果依次通过主键查找 departments 中的数据。SQLite 只支持一种连接实现&＃xff0c;也就是 nested loops join。

另外&＃xff0c;SQLite 中的简单EXPLAIN也可以用于显示执行该语句的虚拟机指令序列&＃xff1a;

sqlite> EXPLAIN...> SELECT e.first_name,e.last_name,e.salary,d.department_name...> FROM employees e...> JOIN departments d ON (e.department_id &＃61; d.department_id)...> WHERE e.salary > 15000; addr opcode p1 p2 p3 p4 p5 comment ---- ------------- ---- ---- ---- ------------- -- ------------- 0 Init 0 15 0 00 Start at 15 1 OpenRead 0 5 0 11 00 root&＃61;5 iDb&＃61;0; employees 2 OpenRead 1 2 0 2 00 root&＃61;2 iDb&＃61;0; departments 3 Rewind 0 14 0 00 4 Column 0 7 1 00 r[1]&＃61;employees.salary 5 Le 2 13 1 (BINARY) 53 if r[1]<&＃61;r[2] goto 13 6 Column 0 10 3 00 r[3]&＃61;employees.department_id 7 SeekRowid 1 13 3 00 intkey&＃61;r[3] 8 Column 0 1 4 00 r[4]&＃61;employees.first_name 9 Column 0 2 5 00 r[5]&＃61;employees.last_name 10 Column 0 7 6 00 r[6]&＃61;employees.salary 11 Column 1 1 7 00 r[7]&＃61;departments.department_name 12 ResultRow 4 4 0 00 output&＃61;r[4..7] 13 Next 0 4 0 01 14 Halt 0 0 0 00 15 Transaction 0 0 8 0 01 usesStmtJournal&＃61;0 16 Integer 15000 2 0 00 r[2]&＃61;15000 17 Goto 0 1 0 00

关于 SQLite 的执行计划和优化器相关信息&＃xff0c;可以参考 SQLite 官方文档解释查询计划。

想为博主点赞&＃xff1f;

想要请教博主&＃xff1f;

扫描下方二维码&＃xff0c;快速获取与博主直面沟通的方式吧&＃xff01;

推荐阅读

☞和疫情赛跑 30 天&＃xff0c;湖北武汉的程序员们怎么样了&＃xff1f;

Web 爬虫现已合法&＃xff1f;

☞科技驰援背后&＃xff1a;技术没有假期&＃xff01;

假期延长&＃xff0c;抢票软件到底还行不&＃xff1f;

☞火神山医院完工&＃xff0c;2月3日收治病人&＃xff01;“云监工”请放心&＃xff01;

阿里腾讯华为在行动&＃xff01;程序员远程办公究竟用哪个视频会议好&＃xff1f;

☞疫情肆虐下&＃xff0c;程序员们都在哪里&＃xff1f;

☞延迟上班别发愁&＃xff0c;远程办公抗疫情&＃xff01;

你点的每一个在看&＃xff0c;我认真当成了喜欢

推荐阅读

select
数据库的存储结构及其重要性

本文介绍了数据库的存储结构及其重要性，强调了关系数据库范例中将逻辑存储与物理存储分开的必要性。通过逻辑结构和物理结构的分离，可以实现对物理存储的重新组织和数据库的迁移，而应用程序不会察觉到任何更改。文章还展示了Oracle数据库的逻辑结构和物理结构，并介绍了表空间的概念和作用。 ... [详细]

蜡笔小新 2023-12-14 16:00:02
text
如何限制php数据库链接数和连接超时时间？

本文介绍了如何使用php限制数据库插入的条数并显示每次插入数据库之间的数据数目，以及避免重复提交的方法。同时还介绍了如何限制某一个数据库用户的并发连接数，以及设置数据库的连接数和连接超时时间的方法。最后提供了一些关于浏览器在线用户数和数据库连接数量比例的参考值。 ... [详细]

蜡笔小新 2023-12-14 14:06:10
int
Redis数据结构之string应用场景解析

本文介绍了Redis的基础数据结构string的应用场景，并以面试的形式进行问答讲解，帮助读者更好地理解和应用Redis。同时，描述了一位面试者的心理状态和面试官的行为。 ... [详细]

蜡笔小新 2023-12-14 14:02:42
text
Spring特性实现接口多类的动态调用详解

本文详细介绍了如何使用Spring特性实现接口多类的动态调用。通过对Spring IoC容器的基础类BeanFactory和ApplicationContext的介绍，以及getBeansOfType方法的应用，解决了在实际工作中遇到的接口及多个实现类的问题。同时，文章还提到了SPI使用的不便之处，并介绍了借助ApplicationContext实现需求的方法。阅读本文，你将了解到Spring特性的实现原理和实际应用方式。 ... [详细]

蜡笔小新 2023-12-14 03:24:19
select
图解redis的持久化存储机制RDB和AOF的原理和优缺点

本文通过图解的方式介绍了redis的持久化存储机制RDB和AOF的原理和优缺点。RDB是将redis内存中的数据保存为快照文件，恢复速度较快但不支持拉链式快照。AOF是将操作日志保存到磁盘，实时存储数据但恢复速度较慢。文章详细分析了两种机制的优缺点，帮助读者更好地理解redis的持久化存储策略。 ... [详细]

蜡笔小新 2023-12-13 20:24:11
text
java 线程死锁模拟

1，关于死锁的理解死锁，我们可以简单的理解为是两个线程同时使用同一资源，两个线程又得不到相应的资源而造成永无相互等待的情况。 2，模拟死锁背景介绍：我们创建一个朋友 ... [详细]

蜡笔小新 2023-12-13 19:12:25
select
高质量SQL书写的30条建议

本文提供了30条关于优化SQL的建议，包括避免使用select *，使用具体字段，以及使用limit 1等。这些建议是基于实际开发经验总结出来的，旨在帮助读者优化SQL查询。 ... [详细]

蜡笔小新 2023-12-13 13:24:33
const
Hibernate基础映射

在说Hibernate映射前，我们先来了解下对象关系映射ORM。ORM的实现思想就是将关系数据库中表的数据映射成对象，以对象的形式展现。这样开发人员就可以把对数据库的操作转化为对 ... [详细]

蜡笔小新 2023-12-14 10:57:47
const
SpringBoot集成前端模版（thymeleaf）的配置步骤

本文介绍了在SpringBoot中集成thymeleaf前端模版的配置步骤，包括在application.properties配置文件中添加thymeleaf的配置信息，引入thymeleaf的jar包，以及创建PageController并添加index方法。 ... [详细]

蜡笔小新 2023-12-14 10:11:46
const
数据库知识集合

数据库（外键及其约束理解）（https:www.cnblogs.comchenxiaoheip6909318.html）My ... [详细]

蜡笔小新 2023-12-13 19:24:01
const
解决Mac上无法使用localhost连接mysql的问题

本文介绍了在Mac上搭建php环境后无法使用localhost连接mysql的问题，并通过将localhost替换为127.0.0.1或本机IP解决了该问题。文章解释了localhost和127.0.0.1的区别，指出了使用socket方式连接导致连接失败的原因。此外，还提供了相关链接供读者深入了解。 ... [详细]

蜡笔小新 2023-12-13 17:48:58
import
计算机网络初识及通信流程分析

本文介绍了计算机网络的定义和通信流程，包括客户端编译文件、二进制转换、三层路由设备等。同时，还介绍了计算机网络中常用的关键词，如MAC地址和IP地址。 ... [详细]

蜡笔小新 2023-12-13 16:50:29
config
解决VS写C#项目导入MySQL数据源报错“You have a usable connection already”问题的正确方法

本文介绍了在VS写C#项目导入MySQL数据源时出现报错“You have a usable connection already”的问题，并给出了正确的解决方法。详细描述了问题的出现情况和报错信息，并提供了解决该问题的步骤和注意事项。 ... [详细]

蜡笔小新 2023-12-13 16:31:57
client
ABAP开发发送邮件程序的配置和代码整理

本文介绍了通过ABAP开发往外网发邮件的需求，并提供了配置和代码整理的资料。其中包括了配置SAP邮件服务器的步骤和ABAP写发送邮件代码的过程。通过RZ10配置参数和icm/server_port_1的设定，可以实现向Sap User和外部邮件发送邮件的功能。希望对需要的开发人员有帮助。摘要长度：184字。 ... [详细]

蜡笔小新 2023-12-13 15:50:17
select
MySQL表分区的创建、增加和删除方法详解

本文详细介绍了MySQL表分区的创建、增加和删除方法，包括查看分区数据量和全库数据量的方法。欢迎大家阅读并给予点评。 ... [详细]

蜡笔小新 2023-12-13 12:26:11

命运2502901041_350

这个家伙很懒，什么也没留下！

Tags | 热门标签

RankList | 热门文章