#青训营笔记创作活动# 问题描述
小F被神秘力量带入了一个魔幻世界,这里危机四伏。为了在异世界中生存,小F需要找到安全区。异世界可以被表示为一个大小为n x m的二维数组,每个格子的值代表该位置的危险程度。
小F的能力值为X,当某个格子的危险程度小于等于X时,这个格子是安全的。如果多个安全的格子相邻(上下左右连通),它们可以构成一个安全区。你需要帮助小F计算出一共有多少个安全区。
测试样例
样例1:
输入:n = 3, m = 3, X = 4, a = [[2, 3, 3], [3, 3, 3], [3, 3, 3]]
输出:1
样例2:
输入:n = 2, m = 2, X = 5, a = [[6, 6], [6, 4]]
输出:1
样例3:
输入:n = 3, m = 3, X = 3, a = [[1, 2, 2], [2, 3, 3], [3, 4, 5]]
输出:1
题解:
一个原二维数组,新建一个visited数组记录是否经过,直接全部遍历,遇到安全值小于能力值且没经过的点就进入while循环。while循环通过队列实现安全区域的搜寻,通过maxnum记录安全区域的个数。
#青训营笔记创作活动#
1月23日 打卡day44
今日学习
今天的内容关于SQL语句。
面对一个较为复杂或较难实现的业务需求时,就可以按照需求进行逐步拆分,化繁为简后逐步实现。其实对于这个道理很多人都懂,但往往在实际编写SQL时却想着一步到位,这也是我接触很多程序员后发现的问题:经验尚未丰富的开发,面对一个需求时通常都想着从头写到尾。但这样写就很容易卡壳,对于简单的业务需求可以这样做,但面对复杂业务时一定要先拆解需求后再逐步实现。
一个查询条件会依赖于另一条SQL的执行结果来决定,很多人在这种情况下会直接组合起来一起写,但这会导致编写SQL的复杂度再次提升,因此在这种情况下,可以先用指定值作为条件去查询,例如xx = "xxx",后面等整体SQL完成后,再套入SQL。
每条SQL的执行效率也要可控。
查询时尽量不要使用*,会导致分析成本变高,网络开销变大,内存占用变高,维护性变差。
连表查询时尽量不要关联太多表。
多表查询时一定要以小驱大。
不要使用like左模糊和全模糊查询。
查询时尽量不要对字段做空值判断。
不要在条件查询=前对字段做任何运算。
!=、!<>、not in、not like、or...要慎用。
必要情况下可以强制指定索引。
避免频繁创建、销毁临时表。
尽量将大事务拆分为小事务执行。
从业务设计层面减少大量数据返回的情况。
尽量避免深分页的情况出现。
SQL务必要写完整,不要使用缩写法。
基于联合索引查询时请务必确保字段的顺序性。
客户端的一些操作可以批量化完成。
明确仅返回一条数据的语句可以使用limit 1。
客户端访问时,能够在1s内得到响应,用户会觉得系统响应很快,体验非常好。 客户端访问时,1~3秒内得到响应,处于可以接受的阶段,其体验感还算不错。 客户端访问时,需要等待3~5秒时才可响应,这是用户就感觉比较慢了,体验有点糟糕。 客户端访问时,一旦响应超过5秒,用户体验感特别糟糕,通常会选择离开或刷新重试。
改善SQL的写法,理解一些SQL导致索引失效的场景,以及撰写SQL时的一些技巧,就能写出一手优质SQL。
1月23日 打卡day44
今日学习
今天的内容关于SQL语句。
面对一个较为复杂或较难实现的业务需求时,就可以按照需求进行逐步拆分,化繁为简后逐步实现。其实对于这个道理很多人都懂,但往往在实际编写SQL时却想着一步到位,这也是我接触很多程序员后发现的问题:经验尚未丰富的开发,面对一个需求时通常都想着从头写到尾。但这样写就很容易卡壳,对于简单的业务需求可以这样做,但面对复杂业务时一定要先拆解需求后再逐步实现。
一个查询条件会依赖于另一条SQL的执行结果来决定,很多人在这种情况下会直接组合起来一起写,但这会导致编写SQL的复杂度再次提升,因此在这种情况下,可以先用指定值作为条件去查询,例如xx = "xxx",后面等整体SQL完成后,再套入SQL。
每条SQL的执行效率也要可控。
查询时尽量不要使用*,会导致分析成本变高,网络开销变大,内存占用变高,维护性变差。
连表查询时尽量不要关联太多表。
多表查询时一定要以小驱大。
不要使用like左模糊和全模糊查询。
查询时尽量不要对字段做空值判断。
不要在条件查询=前对字段做任何运算。
!=、!<>、not in、not like、or...要慎用。
必要情况下可以强制指定索引。
避免频繁创建、销毁临时表。
尽量将大事务拆分为小事务执行。
从业务设计层面减少大量数据返回的情况。
尽量避免深分页的情况出现。
SQL务必要写完整,不要使用缩写法。
基于联合索引查询时请务必确保字段的顺序性。
客户端的一些操作可以批量化完成。
明确仅返回一条数据的语句可以使用limit 1。
客户端访问时,能够在1s内得到响应,用户会觉得系统响应很快,体验非常好。 客户端访问时,1~3秒内得到响应,处于可以接受的阶段,其体验感还算不错。 客户端访问时,需要等待3~5秒时才可响应,这是用户就感觉比较慢了,体验有点糟糕。 客户端访问时,一旦响应超过5秒,用户体验感特别糟糕,通常会选择离开或刷新重试。
改善SQL的写法,理解一些SQL导致索引失效的场景,以及撰写SQL时的一些技巧,就能写出一手优质SQL。
展开
评论
1