优化器刺客之limit 1--Order by col limit n 代价预估优化探索

一、现象

order by 排序加了limit后更慢了？

test=# explain analyze  select userid from dba_users where  username like '%aaaaaaaaaaaaaaaaaa%' order by userid ;QUERY PLAN                                                                  
----------------------------------------------------------------------------------------------------------------------------------------------Sort  (cost=2327.46..2328.96 rows=600 width=4) (actual time=109.316..109.318 rows=0 loops=1)Sort Key: useridSort Method: quicksort  Memory: 25kB->  Bitmap Heap Scan on dba_users  (cost=61.47..2299.78 rows=600 width=4) (actual time=109.311..109.312 rows=0 loops=1)Recheck Cond: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Rows Removed by Index Recheck: 40904Heap Blocks: exact=31502->  Bitmap Index Scan on dba_users_username_idx  (cost=0.00..61.32 rows=600 width=0) (actual time=22.520..22.520 rows=40904 loops=1)Index Cond: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Planning Time: 0.149 msExecution Time: 109.350 ms
(11 rows)test=# 
test=# explain analyze  select userid from dba_users where  username like '%aaaaaaaaaaaaaaaaaa%'    order by userid   limit 1 ;                                                                                                         QUERY PLAN                                                          
---------------------------------------------------------------------------------------------------------------------------------------------Limit  (cost=0.43..408.59 rows=1 width=4) (actual time=3558.960..3558.961 rows=0 loops=1)->  Index Scan using dba_users_pkey on dba_users  (cost=0.43..244895.74 rows=600 width=4) (actual time=3558.958..3558.959 rows=0 loops=1)Filter: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Rows Removed by Filter: 6000000Planning Time: 0.171 msExecution Time: 3558.983 ms
(6 rows)test=#

dba_users有600w条数据，username符合检索条件的0行， order by userid limit 1 耗时3558.983 ms，order by userid 耗时109.350 ms。
limit 1是匹配到第一条数据后就返回，这里却更慢了？ 看起来不符合预期。
表结构如下：

test=# \d+ dba_usersTable "public.dba_users"Column  |         Type          | Collation | Nullable | Default | Storage  | Compression | Stats target | Description 
----------+-----------------------+-----------+----------+---------+----------+-------------+--------------+-------------userid   | integer               |           | not null |         | plain    |             |              | username | character varying(64) |           |          |         | extended |             |              | password | character varying(64) |           |          |         | extended |             |              | 
Indexes:"dba_users_pkey" PRIMARY KEY, btree (userid)"dba_users_password_idx" btree (password)"dba_users_username_idx" gin (username gin_trgm_ops)
Access method: heaptest=#通常我们可以给order by字段做运算或者类型转换来矫正优化器走实际更优的执行计划。
test=# explain analyze select userid from dba_users where  username like '%aaaaaaaaaaaaaaaaaa%' order by userid + 0 limit 1;QUERY PLAN                                                                     
----------------------------------------------------------------------------------------------------------------------------------------------------Limit  (cost=2302.78..2304.28 rows=1 width=4) (actual time=109.117..109.119 rows=0 loops=1)->  Sort  (cost=2302.78..2304.28 rows=600 width=4) (actual time=109.116..109.117 rows=0 loops=1)Sort Key: ((userid + 0))Sort Method: quicksort  Memory: 25kB->  Bitmap Heap Scan on dba_users  (cost=61.47..2299.78 rows=600 width=4) (actual time=109.110..109.111 rows=0 loops=1)Recheck Cond: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Rows Removed by Index Recheck: 40904Heap Blocks: exact=31502->  Bitmap Index Scan on dba_users_username_idx  (cost=0.00..61.32 rows=600 width=0) (actual time=20.856..20.856 rows=40904 loops=1)Index Cond: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Planning Time: 0.156 msExecution Time: 109.149 ms
(12 rows)test=#

或者order by字段和where字段建个组合索引？ 多列统计信息？这些都是一些规避的方法，优化器自身为什么选择了不优的计划？

二、分析

这个问题一直被诟病，不少文章分析过很多场景，统计信息不准？索引损坏？数据分布问题？我们一起深入探索其中的奥秘。
PostgreSQL的优化器是自底向上生成执行计划，当查询小于12个表，使用的是动态规划算法，在每个计划节点执行各种可能的path和检索方法，然后计算出最小代价path作为最优解，也就是最终的执行计划。

DEBUG跟踪这个过程。
limit 的cost计算是在adjust_limit_rows_costs函数里进行的，根据上一节点subpath的startup_cost和total_cost计算出limit count后对应的cost

如下subpath是T_IndexPath, startup_cost=0.4325 total_cost=244895.745
limit 1对应的startup_cost=0.4325 total_cost= startup_cost + (input_total_cost - input_startup_cost) count_rows / input_rows;
= 0.4325 + (244895.745 - 0.4325 ) * 1/600
= 408.5913541666666667
这个对应的是order by userid limit 1执行计划的cost：Limit (cost=0.43…408.59 rows=1 width=4)

在set_cheapest里比较表扫描的最优方式，循环比较pathlist的每个节点的startup_cost和total_cost，
以下最优total_cost是T_BitmapHeapPath,最优startup_cost是T_seqScan

最终set_cheapest函数里一直角逐出Limit节点最优的startup_cost是0.4325，total_cost是408.59135416666669，这个对应到了order by userid Limit 1 这个plan的total_cost：Limit (cost=0.43…408.59 rows=1 width=4)

在get_cheapest_fractional_path函数里返回best_path 也就是以上total_cost=408.59135416666669的path，即order by userid Limit 1的plan。
并以此创建执行计划，最终执行器执行。

那么从整个过程来看，我们需要关注的是整个计划最终节点的startup_cost和total_cost，优化器会选择最优total_cost的path作为best_path。
代价预估order by userid limit 1时，total_cost为：408.59（实际执行的total_time为：3558.961 ms）
预估order by userid + 0 limit 1时，total_cost为：2304.28（实际执行的total_time为：109.119 ms）
显而易见优化器选择了total_cost更小的408.59所在的path作为执行计划。
很明显代价预估有问题，我们开始就跟踪了order by userid limit 1的cost计算，计算的数值本身没有问题。
是优化器的缺陷？再把执行计划拉出来遛遛。

test=# explain analyze  select userid from dba_users where  username like '%aaaaaaaaaaaaaaaaaa%'    order by userid   limit 1 ;                                                                                                         QUERY PLAN                                                          
---------------------------------------------------------------------------------------------------------------------------------------------Limit  (cost=0.43..408.59 rows=1 width=4) (actual time=3558.960..3558.961 rows=0 loops=1)->  Index Scan using dba_users_pkey on dba_users  (cost=0.43..244895.74 rows=600 width=4) (actual time=3558.958..3558.959 rows=0 loops=1)Filter: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Rows Removed by Filter: 6000000Planning Time: 0.171 msExecution Time: 3558.983 ms
(6 rows)test=#

cost我们之前已经计算过了，但是从actual time来看，代价预估偏差还是比较大的，
cost：Index Scan startup_cost=0.43 total_cost=244895.74 ， limit startup_cost=0.43 total_cost=408.59
从预估来看因为没有offset 所以startup_cost都是0.43，根据公式计算的 limit 的total_cost=408.59，比244895.74小了很多。

actual: Index Scan startup_time=3558.958 total_time=3558.959，limit startup_time=3558.960 total_time=3558.961
从实际执行来看Index startup_time=3558.958 total_time=3558.959，索引扫描startup_time启动代价3558.958ms？

startup_time可以理解为扫描到第一条数据的时间，这里可以虽然走了userid的pkey索引，但是根据username like ‘%aaaaaaaaaaaaaaaaaa%’ filter了600w行，就是说回表匹配了一遍所有行，因此耗时主要是在这里。

再看下limit 节点total_cost计算代价公式

*total_cost=startup_cost + (input_total_cost - input_startup_cost) count_rows / input_rows
总代价 = 父节点启动代价 + （总代价 - 启动代价）即父节点运行代价 * limit 行数/ 预估输出的总行数

这里在where 条件不含排序字段走排序字段索引情况下，有可能通过索引匹配到第一条符合条件的数据会比较久，就是说要考虑索引扫描的整体代价作为limit的启动代价（当前默认逻辑是通过索引很快找到第一条数据，然后输出limit n行，因此整体cost在这个场景下是偏小的），最极端的场景很可能是先扫描了整个索引并且回表去匹配数据，这个cost要预估进去。

因此这里的startup_cost 需要替换为total_cost, 计算公式可以调整为：
*total_cost=total_cost + (input_total_cost - input_startup_cost) count_rows / input_rows

三、方案

当where 条件不含order by字段走order by字段索引不进行sort的情况下，flag（limit_total_cost）会置为true，这个时候就走新的计算逻辑。

        if (count_est != 0){double          count_rows;if (count_est > 0) count_rows = (double) count_est;elsecount_rows = clamp_row_est(input_rows * 0.10);if (count_rows > *rows)count_rows = *rows;if (input_rows > 0){if (limit_total_cost){*total_cost = *total_cost + (input_total_cost - input_startup_cost)* count_rows / input_rows;}else*total_cost = *startup_cost +(input_total_cost - input_startup_cost)* count_rows / input_rows;}*rows = count_rows;if (*rows < 1)*rows = 1;}
}

四、验证

执行计划显示order by userid limit 1和之前order by userid +0 limit 1的执行计划相同，sql耗时符合预期。

test=# explain analyze  select userid from dba_users where  username like '%aaaaaaaaaaaaaaaaaa%' order by userid limit 1 ;QUERY PLAN                                                                     
----------------------------------------------------------------------------------------------------------------------------------------------------Limit  (cost=2302.78..2304.28 rows=1 width=4) (actual time=140.581..140.585 rows=0 loops=1)->  Sort  (cost=2302.78..2304.28 rows=600 width=4) (actual time=140.576..140.579 rows=0 loops=1)Sort Key: useridSort Method: quicksort  Memory: 25kB->  Bitmap Heap Scan on dba_users  (cost=61.47..2299.78 rows=600 width=4) (actual time=140.534..140.536 rows=0 loops=1)Recheck Cond: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Rows Removed by Index Recheck: 40904Heap Blocks: exact=31502->  Bitmap Index Scan on dba_users_username_idx  (cost=0.00..61.32 rows=600 width=0) (actual time=22.800..22.802 rows=40904 loops=1)Index Cond: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Planning Time: 1.413 msExecution Time: 141.032 ms
(12 rows)test=#

再验证一个稍微复杂一点的场景。
修改前：

test=# explain analyze  select userid from dba_users where  username like '%aaaaaaaaaaaaaaaaaa%'   and userid in (select city_id from measurement where logdate > '2023-02-01' and logdate < '2023-05-01' and name like '%Nickyoung%' order by city_id   limit 5) ;QUERY PLAN                                                                                                
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Nested Loop  (cost=2143.01..2185.00 rows=1 width=4) (actual time=8153.711..8153.717 rows=0 loops=1)->  HashAggregate  (cost=2142.57..2142.62 rows=5 width=4) (actual time=8153.710..8153.713 rows=0 loops=1)Group Key: measurement.city_idBatches: 1  Memory Usage: 24kB->  Limit  (cost=1.32..2142.56 rows=5 width=4) (actual time=8153.707..8153.710 rows=0 loops=1)->  Merge Append  (cost=1.32..582419.24 rows=1360 width=4) (actual time=8153.705..8153.708 rows=0 loops=1)Sort Key: measurement.city_id->  Index Scan using measurement_y2023m02_city_id_idx on measurement_y2023m02 measurement_1  (cost=0.43..59989.39 rows=140 width=4) (actual time=855.005..855.005 rows=0 loops=1)Filter: ((logdate > '2023-02-01'::date) AND (logdate < '2023-05-01'::date) AND ((name)::text ~~ '%Nickyoung%'::text))Rows Removed by Filter: 1399554->  Index Scan using measurement_y2023m03_city_id_idx on measurement_y2023m03 measurement_2  (cost=0.43..265374.77 rows=620 width=4) (actual time=3747.483..3747.483 rows=0 loops=1)Filter: ((logdate > '2023-02-01'::date) AND (logdate < '2023-05-01'::date) AND ((name)::text ~~ '%Nickyoung%'::text))Rows Removed by Filter: 6197829->  Index Scan using measurement_y2023m04_city_id_idx on measurement_y2023m04 measurement_3  (cost=0.43..257037.48 rows=600 width=4) (actual time=3551.214..3551.214 rows=0 loops=1)Filter: ((logdate > '2023-02-01'::date) AND (logdate < '2023-05-01'::date) AND ((name)::text ~~ '%Nickyoung%'::text))Rows Removed by Filter: 6001729->  Memoize  (cost=0.44..8.46 rows=1 width=4) (never executed)Cache Key: measurement.city_idCache Mode: logical->  Index Scan using dba_users_pkey on dba_users  (cost=0.43..8.45 rows=1 width=4) (never executed)Index Cond: (userid = measurement.city_id)Filter: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Planning Time: 3.282 msExecution Time: 8153.877 ms
(24 rows)test=#

修改后：

test=# explain analyze  select userid from dba_users where  username like '%aaaaaaaaaaaaaaaaaa%'   and userid in (select city_id from measurement where logdate > '2023-02-01' and logdate < '2023-05-01' and name like '%Nickyoung%' order by city_id   limit 5) ;QUERY PLAN                                                                                
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Nested Loop  (cost=5982.58..6024.57 rows=1 width=4) (actual time=0.129..0.131 rows=0 loops=1)->  HashAggregate  (cost=5982.13..5982.18 rows=5 width=4) (actual time=0.128..0.130 rows=0 loops=1)Group Key: measurement.city_idBatches: 1  Memory Usage: 24kB->  Limit  (cost=5982.11..5982.12 rows=5 width=4) (actual time=0.126..0.127 rows=0 loops=1)->  Sort  (cost=5982.11..5985.51 rows=1360 width=4) (actual time=0.124..0.126 rows=0 loops=1)Sort Key: measurement.city_idSort Method: quicksort  Memory: 25kB->  Append  (cost=177.08..5959.52 rows=1360 width=4) (actual time=0.109..0.110 rows=0 loops=1)->  Bitmap Heap Scan on measurement_y2023m02 measurement_1  (cost=177.08..696.08 rows=140 width=4) (actual time=0.041..0.041 rows=0 loops=1)Recheck Cond: ((name)::text ~~ '%Nickyoung%'::text)Filter: ((logdate > '2023-02-01'::date) AND (logdate < '2023-05-01'::date))->  Bitmap Index Scan on measurement_y2023m02_name_idx  (cost=0.00..177.05 rows=140 width=0) (actual time=0.039..0.039 rows=0 loops=1)Index Cond: ((name)::text ~~ '%Nickyoung%'::text)->  Bitmap Heap Scan on measurement_y2023m03 measurement_2  (cost=377.60..2665.41 rows=620 width=4) (actual time=0.031..0.031 rows=0 loops=1)Recheck Cond: ((name)::text ~~ '%Nickyoung%'::text)Filter: ((logdate > '2023-02-01'::date) AND (logdate < '2023-05-01'::date))->  Bitmap Index Scan on measurement_y2023m03_name_idx  (cost=0.00..377.45 rows=620 width=0) (actual time=0.031..0.031 rows=0 loops=1)Index Cond: ((name)::text ~~ '%Nickyoung%'::text)->  Bitmap Heap Scan on measurement_y2023m04 measurement_3  (cost=377.50..2591.23 rows=600 width=4) (actual time=0.036..0.036 rows=0 loops=1)Recheck Cond: ((name)::text ~~ '%Nickyoung%'::text)Filter: ((logdate > '2023-02-01'::date) AND (logdate < '2023-05-01'::date))->  Bitmap Index Scan on measurement_y2023m04_name_idx  (cost=0.00..377.35 rows=600 width=0) (actual time=0.036..0.036 rows=0 loops=1)Index Cond: ((name)::text ~~ '%Nickyoung%'::text)->  Memoize  (cost=0.44..8.46 rows=1 width=4) (never executed)Cache Key: measurement.city_idCache Mode: logical->  Index Scan using dba_users_pkey on dba_users  (cost=0.43..8.45 rows=1 width=4) (never executed)Index Cond: (userid = measurement.city_id)Filter: ((username)::text ~~ '%aaaaaaaaaaaaaaaaaa%'::text)Planning Time: 2.047 msExecution Time: 0.254 ms
(32 rows)test=#

五、小结

也算牛刀小试修正了下limit的cost预估。不过这种修改方式看起来是不优雅不专业的，内核中可能有很多特例，我们不可能只是一股脑堆if else switch case逻辑。就像Linus说的，排除特例完美覆盖所有情况才是好的代码。

针对这个case，我认为优化器目前limit节点的cost计算逻辑需要加强，计算公式可能需要更复杂的关系因子，或者使用更合理的数学表达式。鄙人不才，还需持续学习积累。

代价预估在一些特定场景下难免会有偏差，其中统计信息不准导致的场景可能会多一些，可以参考这篇了解下统计信息的原理<深入浅出统计信息内核原理(上)：Compressed Histogram>。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/248391.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

第4章 python深度学习——（波斯美女）

第4章 python深度学习——（波斯美女）

第4章 机器学习基础 本章包括以下内容&#xff1a; 除分类和回归之外的机器学习形式 评估机器学习模型的规范流程 为深度学习准备数据 特征工程 解决过拟合 处理机器学习问题的通用工作流程 学完第 3 章的三个实例&#xff0c;你应该已经知道如何用神经网络解决分类问题和回归…
阅读更多...
调试小结：PHY初始化前后Link Status是否能正确反应网线插上、拔下状态

调试小结：PHY初始化前后Link Status是否能正确反应网线插上、拔下状态

1 说明 为了验证是否需要初始化PHY才能检测到网线插上、拔下&#xff0c;这里我们对比初始化PHY&#xff08;LAN8720&#xff09;前后&#xff0c;插拔网线PHY寄存器1的bit2的是否按照预期变化来进行测试。 我们查看的PHY寄存器是1的bit2&#xff0c;定义如下&#xff1a; 2…
阅读更多...
anaconda离线安装包的方法

anaconda离线安装包的方法

当设备没有网络时&#xff0c;可以使用有网络的设备先下载所需安装包&#xff0c;然后离线拷贝到需要安装的设备&#xff0c;最后安装。 一. 下载所需安装包 下载命令&#xff1a;使用pip download。详细描述参见pip download -h 以"blind-watermark"为例。 pip …
阅读更多...
asp.net core监听本地ip地址

asp.net core监听本地ip地址

开发asp.net core的时候遇到一个问题我想提供访问供其他同事测试&#xff0c;但是默认都是localhost或者127.0.0.1。我想换成我的Ip地址访问但是不行&#xff0c;百度搜索需要更换监听的地址即修改launchSettings.json&#xff0c;修改为0.0.0.0:5248&#xff0c;这样不管local…
阅读更多...
回归预测 | Matlab实现CPO-SVR冠豪猪优化支持向量机的数据多输入单输出回归预测

回归预测 | Matlab实现CPO-SVR冠豪猪优化支持向量机的数据多输入单输出回归预测

回归预测 | Matlab实现CPO-SVR冠豪猪优化支持向量机的数据多输入单输出回归预测 目录 回归预测 | Matlab实现CPO-SVR冠豪猪优化支持向量机的数据多输入单输出回归预测预测效果基本描述程序设计参考资料 预测效果 基本描述 1.Matlab实现CPO-SVR冠豪猪优化支持向量机的数据多输入…
阅读更多...
visual studio2022专业版安装步骤

visual studio2022专业版安装步骤

目录 一、Visual studio下载二、创建C#项目——Hello World三、专业版秘钥激活 一、Visual studio下载 首先进入下载官网 先下载2022专业版&#xff0c;等等后面还需要选环境 我勾选了以下几个和c#开发有关的&#xff0c;后面缺什么还可以再安装所有以少勾了问题也不大 然后…
阅读更多...
故障脚本的重要作用：预防、诊断与恢复

故障脚本的重要作用：预防、诊断与恢复

故障脚本是在信息技术和计算机领域中广泛使用的一种自动化工具&#xff0c;它们的主要目的是预测、诊断和修复系统或软件中的故障。这些脚本在现代技术环境中扮演着至关重要的角色&#xff0c;本文将介绍故障脚本的主要作用。 一、预防性作用 监控和预警 故障脚本可以用于监控系…
阅读更多...
C# 一个快速读取写入操作execl的方法封装

C# 一个快速读取写入操作execl的方法封装

这里封装了3个实用类ExcelDataReaderExtensions&#xff0c;ExcelDataSetConfiguration&#xff0c;ExcelDataTableConfiguration和一个实用代码参考&#xff1a; using ExcelDataReader; using System; using System.Collections.Generic; using System.Linq; using System.T…
阅读更多...
GitHub国内打不开（解决办法有效）

GitHub国内打不开（解决办法有效）

最近国内访问github.com经常打不开&#xff0c;无法访问。 github网站打不开的解决方法 1.打开网站http://tool.chinaz.com/dns/ &#xff0c;在A类型的查询中输入 github.com&#xff0c;找出最快的IP地址。 2.修改hosts文件。 在hosts文件中添加&#xff1a; # localhost n…
阅读更多...
leetcode 27.移除元素（python版）

leetcode 27.移除元素（python版）

需求 给你一个数组 nums 和一个值 val&#xff0c;你需要 原地 移除所有数值等于 val 的元素&#xff0c;并返回移除后数组的新长度。 不要使用额外的数组空间&#xff0c;你必须仅使用 O(1) 额外空间并 原地 修改输入数组。 元素的顺序可以改变。你不需要考虑数组中超出新长度…
阅读更多...
【新课】安装部署系列Ⅲ—Oracle 19c Data Guard部署之两节点RAC部署实战

【新课】安装部署系列Ⅲ—Oracle 19c Data Guard部署之两节点RAC部署实战

本课程由云贝教育-刘峰老师出品&#xff0c;感谢关注 课程介绍 Oracle Real Application Clusters (RAC) 是一种跨多个节点分布数据库的企业级解决方案。它使组织能够通过实现容错和负载平衡来提高可用性和可扩展性&#xff0c;同时提高性能。本课程基于当前主流版本Oracle 1…
阅读更多...
图的学习

图的学习

图的基本概念和术语 图的定义&#xff1a;图是由顶点的有穷非空集合和顶点之间的边的集合组成的&#xff0c;G表示&#xff0c;V是图G中顶点的集合&#xff0c;E是图G中边的集合 无向图&#xff1a;任意两点的边都是无向边组成的图&#xff08;无向边&#xff1a;&#xff08…
阅读更多...
【服务端性能测试】性能测试策略如何做

【服务端性能测试】性能测试策略如何做

一、需求收集 先需要确认本次测试目的是什么&#xff0c;然后再看我们需要用什么参数来判断这个目的是否能够达成。 1.1 业务性能指标参考&#xff1a; TPS、QPS、RT、请求成功率&#xff08;一般请求成功率>99.99%&#xff09; 1.2 硬件性能指标参考&#xff1a; 即服…
阅读更多...
TensorFlow2实战-系列教程11：RNN文本分类3

TensorFlow2实战-系列教程11：RNN文本分类3

&#x1f9e1;&#x1f49b;&#x1f49a;TensorFlow2实战-系列教程 总目录 有任何问题欢迎在下面留言 本篇文章的代码运行界面均在Jupyter Notebook中进行 本篇文章配套的代码资源已经上传 6、构建训练数据 所有的输入样本必须都是相同shape&#xff08;文本长度&#xff0c;…
阅读更多...
Spring | Spring的“数据库开发“ (Srping JDBC)

Spring | Spring的“数据库开发“ (Srping JDBC)

目录&#xff1a; Spring JDBC1.Spring JDBC的核心类 ( JdbcTemplate类 )2.Srping JDBC 的配置3.JdbcTemplate类的“常用方法”execute( )&#xff1a;直接执行“sql语句”&#xff0c;没有返回值update( ) &#xff1a;“增删改”&#xff0c;返回 “影响的行数”query( ) : “…
阅读更多...
86.网游逆向分析与插件开发-物品使用-物品丢弃的逆向分析与C++代码的封装

86.网游逆向分析与插件开发-物品使用-物品丢弃的逆向分析与C++代码的封装

内容参考于&#xff1a;易道云信息技术研究院VIP课 上一个内容&#xff1a;物品使用的逆向分析与C代码的封装-CSDN博客 码云地址&#xff08;ui显示角色数据 分支&#xff09;&#xff1a;https://gitee.com/dye_your_fingers/sro_-ex.git 码云版本号&#xff1a;7563f86877c…
阅读更多...
网络协议与攻击模拟_11DHCP欺骗防护

网络协议与攻击模拟_11DHCP欺骗防护

开启DHCP 监听 ip dhcp snooping 指定监听vlan ip dhcp snooping vlan 1 由于开启监听后&#xff0c;交换机上的接口就全部变成非信任端口&#xff0c; 非信任端口会拒绝DHCP报文&#xff0c;会造成正常的DHCP请求和响应都无法完成。 现在是请求不到IP地址的&#xff0c;…
阅读更多...
添加了gateway之后远程调用失败

添加了gateway之后远程调用失败

前端提示500&#xff0c;后端提示[400 ] during [GET] to [http://userservice/user/1] 原因是这个&#xff0c;因为在请求地址写了两个参数&#xff0c;实际上只传了一个参数 解决方案&#xff1a;加上(required false)并重启所有相关服务
阅读更多...
【pytorch】nn.linear 中为什么是y=xA^T+b

【pytorch】nn.linear 中为什么是y=xA^T+b

我记得读教材的时候是yWxb, 左乘矩阵W&#xff0c;这样才能表示线性变化。 但是pytorch中的nn.linear中&#xff0c;计算方式是yxA^Tb&#xff0c;其中A是权重矩阵。 为什么右乘也能表示线性变化操作呢&#xff1f;因为pytorch中&#xff0c;照顾到输入是多个样本一起算的&…
阅读更多...
基于JDK8的SpringBoot-2.7.6应用程序的jar包能直接通过java -jar 命令运行的原因

基于JDK8的SpringBoot-2.7.6应用程序的jar包能直接通过java -jar 命令运行的原因

文章目录 前言一、JAR是什么？二、嵌套JAR1.java官方不支持嵌套jar读取和加载2.嵌套“shade” jar 方案3.SpringBoot的解决方案三、SpringBoot的Executable Jars1.核心支持模块（spring-boot-loader）2.运行调试工具（JDWP）2.1.保姆级IDEA添加JDWP远程调试示例3.运行调试（jav…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023