最近在好好了解http,发现对介绍http的第一句话【http协议是无状态的,无连接的】就无法理解了:无状态的【状态】到底指的是什么?!
找了很多资料不仅没有发现有一针见血正面回答这个问题的,而且有些解释还充斥了各种错误,看着看着就觉得心里憋着一股浊气吐不出来
于是在看了很多资料之后,我一口吐出浊气,大声正面提出这个问题:http协议无状态中的【状态】到底指的是什么?!
然后开始不断探索解决这个问题。。。
最终很高兴的是我找到了让人满意的答案,先卖个关子,各位如果着急可以直接拉到最下查看
正文:http协议无状态中的【状态】到底指的是什么呢?
先来看这句话的另外两个概念:(标准的http协议是无状态的,无连接的)
标准的http协议指的是不包括cookies, session,application的http协议,他们都不属于标准协议,虽然各种网络应用提供商,实现语言、web容器等,都默认支持它
无连接指的是什么
每一个访问都是无连接,服务器挨个处理访问队列里的访问,处理完一个就关闭连接,这事儿就完了,然后处理下一个新的
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接
对于【无状态】,我看到很多隔着一层磨砂玻璃一样的模糊说法(官方或者教程里的说法),看着非常难受(但其实算是对的)(后来我发现我为什么觉得它看着难受了,因为他们引入了很多新的,而且明显是一个可能用在很多地方的广义名词,这些词最大的作用就是,混淆概念,下面我标注了)
协议对于事务处理没有记忆能力【事物处理】【记忆能力】
对同一个url请求没有上下文关系【上下文关系】
每次的请求都是独立的,它的执行情况和结果与前面的请求和之后的请求是无直接关系的,它不会受前面的请求应答情况直接影响,也不会直接影响后面的请求应答情况【无直接联系】【受直接影响】
服务器中没有保存客户端的状态,客户端必须每次带上自己的状态去请求服务器【状态】
我必须得到确切而具体的解释!
这几点给了我下一步思考的方向:
【服务器中没有保存客户端的状态,客户端必须每次带上自己的状态去请求服务器 】这里的客户端的状态是不是确切地指服务器没有保存客户的信息呢?但显然不是啊
【HTTP无状态的特性严重阻碍了这些应用程序的实现,毕竟交互是需要承前启后的,简单的购物车程序也要知道用户到底在之前选择了什么商品】我对此质疑为什么无状态就不能实现购物车呢?服务器就不能存储东西了么?
【 每次的请求都是独立的,<它的执行情况和结果>与<前面的请求>和<之后的请求>是无直接关系的】我觉得这个说法比较靠谱,但是所谓的不同请求间的没有关系,是指的请求内容没有关系,还是只是指请求本身没有关系?
请求内容没有关系只可能是服务器上不存有用户数据才可能啊,但是显然是存有的啊
请求本身没有关系,这又有什么意义呢,每一次的请求有什么价值?
根据这个方向我做了一个模拟访问实验:假如没有cookie没有session,只有http的时候,那当一个注册用户访问这个购物网站的时候,会发生这些事情:
前提情况:
服务器肯定为每个注册用户建立了数据表,记录用户的数据
http是无连接的
第一步需要登录
用户通过http把用户的用户名和密码发送给服务器,服务器把他们跟自己存有的用户资料对比,如果一致,则返回信息登录成功
然后用户点击某一商品页
这个动作相当于输入一个商品页的网址
假如商品页比较机密不对外公开,需要是用户才能访问
而虽然http能传送用户名和密码,而且刚才也输入了,还验证成功了,但是因为服务器既不会记得你登录的状态,你的客户端也不会存储你刚才输入的用户名和密码
所以因为这一次访问因为无法确定你的身份,只能访问失败
这时候如果要解决这个问题,而且没有cookie没有session,那就只能你在访问网址的同时继续带上你的用户名和密码(继续输入咯)其实就像我现在的APP一样
假设上一步的问题解决了,就是每次访问的时候都会手动输入用户名和密码,然后现在的情况是:你已经选了几件商品在你的购物车中,你想再添加一件商品,于是你点击某个商品旁边的加号
这个动作也相当于输入一个网址,网址的内容是发送一个请求,往你的购物车中加入这个商品
系统首先用你传来的用户名和密码验证你的身份,然后访问你的数据库,在其中的购物车属性下加一条数据,就是这个商品的数据
操作结束后,返回操作成功,并结束访问
OK,实验结束,看似没有cookie没有session也能凑合解决问题,其实两个操作都有很大的问题
你每访问一次需要权限的内容都需要在客户端输入用户名和密码,这一项的繁琐就不必赘述了
你的每一次操作都要与系统底层的数据库进行交互
多次少量的访问存在非常大的性能浪费。非常容易就能想到肯定是一次大量的操作更加有效率,于是就想到了缓存区
你的非重要琐碎数据也被写进数据库中,跟你的主要数据放在一起
一次次添加和删除购物车其实只是跟你这次浏览,或者叫这次会话有关,是临时的数据,跟用户的主要信息无关,它们没什么价值,纯粹的冗余数据(不排除现在有的公司觉得这种数据也有非常大的价值可以让它们巧妙的利用),用什么存放这些临时的数据,我们也很容易想到缓存区
经过这个模拟访问实验,结合前面的思考方向,我们知道了三点:
服务器上肯定存有用户的数据,你提交的增删改查它也能够处理,所以这句话中【服务器中没有保存客户端的状态】的状态并不是指用户的数据,我们的猜测不对
我们的质疑对了,无状态能实现购物车,可以通过服务器上存有的用户数据来实现
但是,使用上面这种方式实现购物车,存在三个比较大的问题。由此,我们不禁会想,这三个问题的解决是不是跟我们不确切了解的【状态】一词有关?于是,接下来我们来通过解决这三个问题来把【状态】的意义探寻下去
由上所述,我们可以在http的基础上增加一些机制来解决上面出现的三个问题
在用户端增加一个记录本是非常有必要的,正好官方加入的cookie机制跟这个一样,它的用处也确实是上面讨论的那样,一般就是用来标识访问者的身份
在服务器增加一个缓存区能同时解决后两个问题
有了这个缓存区作为一个数据缓冲,就不用一次次地访问数据库,浪费大量计算机资源,而是在最后统一归入数据库
有了这个缓存区,你就不用把临时的数据放到数据库中了,只需要在你们交流告一段落之后,再把数据整理,把有用的数据归入数据库
这里就自然引申出了一个重要的概念:会话,它作为一个缓冲存储区被从数据库中分离出来,理由并不生硬,它有其独特的重要且不可替代的作用。这个东西恰好跟官方加入的session机制一样
另外说一个非常具有迷惑性的容易让人对session的主要作用产生偏离的理解:认为session存在的价值就是给访问者分配一个sessionID代替用户名和密码,
为什么非常具有迷惑性,因为session确实做了这件事,而且也起到了很大的作用,所以它是对的,但是只对一半,而且没有涉及问题的本质,这种情况是最危险的(看似很有说服力,把你说服了,所以你很难有动力继续找下去,但是真实情况跟它有偏差,但是偏差不大,所以又很难把你说服回来,只有隐隐的不对劲,这个时候你离真实最近,也离真实最远)
那就顺便说说它为什么是对的,也就是用session做的另一件有用的事:
给每个session一个ID,一方面用来方便自己查询,另一方面把这个ID给用户,用户下一次访问的时候就可以不用用户名和密码,而是直接使用这个ID来表明自己的身份
首先,这个ID安全吗?这个ID比直接传用户名和密码安全吗?
你很容易会想到,本来用户名和密码的组合还特地设置地比较复杂,你这换一组数字就代替了,是不是太不安全了?
我们知道http协议本身是完全不加密的,如果使用用户名和密码,第一次访问是放在http头中,后边自动保存了密码就会放在cookie中,这些都完全没有加密,它的安全性基本为0,就是裸奔了,只要被窃取,那就丢失了
所以,就这个意义来讲,sessionID的安全性跟使用用户名和密码没什么区别
但是其实,虽然http本身不能加密,但是有些软件什么的,能在应用层面手动给你加密,比如QQ就会使用户名密码加临时验证码联合哈希,sessionID加一个时间戳简单加密也是非常常用的方法
而且因为sessionID本身有有效期,即使丢了,也可能很快失效,造成的损失可能没那么大,而用户名跟密码丢了,那就大了
所以总结就是:
不严格加密的sessionID和用户名和密码一样,都不太安全
但是相比较来说,sessionID要安全一些
而使用https是完全安全的
然后,使用sessionID有哪些好处
方便直接根据ID查询用户对应的session
加密的时候计算量小
安全性不会降低,甚至还更高一些
OK,通过独立地解决纯http机制会产生的问题,我们探讨了cookie和session机制的本质。而且想到:【使用http协议,服务器中不会保存客户端的状态】所产生的问题通过增加cookie和session机制解决了,是不是就意味着这个【状态】跟cookie和session的关系非常紧密?所以这个无状态指的是【没有对 本次会话 设置一个缓存区,记录这次会话的状态,缓存区包括服务器端和用户端】但好像还是没有点破关键(主要是觉得跟前面那些官方对状态的说法不太吻合,甚至没有对应关系)
忽然我想到一个问题:一个有状态的http是什么样的?
很难直接想象有状态的http是什么样,因为http这种机制是天然无状态的
那就类比一下吧,另一个天然有状态的机制叫TCP
如果有状态的意思是它的每次请求是有联系的,那么有状态的TCP的样子是:假如一份数据分了三份TCP包发送,那这个包上面会标明这是第几个包,会标明这个包跟那几个包是有联系的,有什么联系
但好像这个有状态的TCP跟我们想要的有状态的HTTP没有关系,因为即使每次http请求之间互相有联系,它也不能解决上面提到的http无状态的问题
诶,等等,好像能类比:
假如每个http连接都有一个签名,于是第一次登陆成功之后,服务器就知道了这个签名是允许登陆的,于是之后所有同样签名的http连接都能登陆,这里利用了同一个用户发出的http连接之间的同主人关系,这里解决了一个保持登录状态的问题
同样,来尝试利用这个【每次http请求之间互相有联系】来解决上面碰到的那个问题【每一次操作都要与系统底层的数据库进行交互】,但想了半天确实无法进行下去
不过我灵机一动,从另一个角度来想,好像解决了这个问题:
只有【每次http请求之间互相有联系】这个条件,无法解决【每一次操作都要与系统底层的数据库进行交互】
因为很明显,要解决【每一次操作都要与系统底层的数据库进行交互】就必须在服务器端开辟一块缓存区
不过如果你思考一下如何实现【每次http请求之间互相有联系】,你就会发现,它也需要在服务器端开辟一块缓存区
所以【在服务器端开辟一块缓存区】才是真正的条件,也就是说,它确实等价于【有状态】
而且我也找到了这个【在服务器端开辟一块缓存区】的条件跟前面那些官方对状态的说法对应的点,那就是:
通过在服务器端开辟一块缓存区,存储、记忆、共享一些临时数据,你就可以:
协议对于事务处理有记忆能力【事物处理】【记忆能力】
对同一个url请求有上下文关系【上下文关系】
每次的请求都是不独立的,它的执行情况和结果与前面的请求和之后的请求是直接关系的【不独立】【直接关系】
服务器中保存客户端的状态【状态】
所以,这个状态,加上前面说的客户端也有cookie,就是指,客户端和服务器在临时会话中产生的数据!而前面也说道了,使用缓存区保存临时会话中的数据是多么重要
所以状态不仅包括不同URL访问之间的关系,还有对其他URL访问的数据记录,还有一些其他的东西,所以更确切地说,状态应该是【实现了这些东西所凭借的后面的缓存空间】中的客户的临时数据
cookie和session应该是完全实现了有状态这个功能
一种常见的对状态的误解:
有人在解释HTTP的无状态时,把它跟有连接对立,说是两种方式,也就是如果想不无状态,就必须有连接,但其实不然
有连接和无连接以及之后的Keep-Alive都是指TCP连接
有状态和无状态可以指TCP也可以指HTTP
TCP一直有状态,HTTP一直无状态,但是应用为了有状态,就给HTTP加了cookie和session机制,让使用http的应用也能有状态,但http还是无状态
开始TCP是有连接,后来TCP无连接,再后来也就是现在TCP是Keep-Alive,有点像有连接。
受够了的HttpClient?那Hutool的HttpUtil值得一试!
一、HttpUtil
快读使用:
发送get请求,包括有参与无参
示例:
String url = "http://www.heckjj.com";
Map<String, Object> paramMap = new HashMap<>();
paramMap.put("query", heck);
// 无参GET请求
String result = HttpUtil.get(url);
// 带参GET请求
String result2 = HttpUtil.get(url, paramMap);
发送post请求
这里直接引用文档的示例:
HashMap<String, Object> paramMap = new HashMap<>();
paramMap.put("city", "北京");
String result= HttpUtil.post("https://www.heckjj.com", paramMap);
//文件上传只需将参数中的键指定(默认file),值设为文件对象即可,对于使用者来说,文件上传与普通表单提交并无区别
paramMap.put("file", FileUtil.file("D:\face.jpg"));
String result= HttpUtil.post("https://www.heckjj.com", paramMap);
对应源码:
/**
* 发送post请求
*
* @param urlString 网址
* @param paramMap post表单数据
* @return 返回数据
*/
public static String post(String urlString, Map<String, Object> paramMap) {
return HttpRequest.post(urlString).form(paramMap).execute().body();
}
/**
* 发送post请求
*
* @param urlString 网址
* @param params post表单数据
* @return 返回数据
*/
public static String post(String urlString, String params) {
return HttpRequest.post(urlString).body(params).execute().body();
}
二、HttpRequest与HttpResponse
不满足于高度化的工具类封装,想拥有更多自定义请求与响应处理,可以使用HttpRequest与HttpResponse
快速上手:
String result2 = HttpRequest.post(url)
.header(Header.USER_AGENT, "Hutool http")
.form(paramMap)
.execute().body();
解决方式:
1. 必须使用相对路径读取文件;
假设你的模板文件放在了 resources —> templates —> test.xlsx
2. 只能使用流去读取,不能用file;
// jar里面文件读取方式:
ClassPathResource classPathResource = new ClassPathResource("templates/test.xlsx");
// 获取文件流
classPathResource .getInputStream();
如果要将流存储到数组中如下:
/**
* 输出流转字节数组
* @param input 输出流
* @return 字节数组
*/
public static byte[] toByteArray(InputStream input) throws IOException {
ByteArrayOutputStream output = new ByteArrayOutputStream();
byte[] buffer = new byte[1024 * 4];
int size = 0;
while (-1 != (size = input.read(buffer))) {
output.write(buffer, 0, size);
}
return output.toByteArray();
}
关于Archetype介绍参考:Introduction to Archetypes
一、Archetype自定义流程:
1、创建模板工程:找到一个现有的项目,进行编辑,将项目中的包结构、各类文件放置到合适的位置;
2、从模板工程创建Archetype:打开cmd窗口,切换当前目录到上面的工程目录下,执行maven命令:
mvn archetype:create-from-project
执行完成后,target/generated-sourced/archetype目录下就是我们需要的项目模板。
3、安装Archetype到本地仓库:cd进入target/generated-sourced/archetype中,执行命令:
mvn -Dmaven.test.skip=true clean install
将自定义Archetype安装到本地仓库即可:此时,自定义archetype就被安装到settings.xml中<localRepository>指定的本地仓库中,我的机器本地目录是D:/q/repos-maven;另外,archetype安装到本地仓库后,会在.m2/archetype-catalog.xml中加入对应的archetype节点,结构如下:
<archetype>
<groupId>com.heckjj.blog</groupId>
<artifactId>crm-archetype-archetype</artifactId>
<version>1.0.0</version>
<description>The parent pom of crm</description>
</archetype>
4、使用自定义Archetype创建工程:
这样我们就创建成功了自定义的Archetype,可以通过命令从本地模板创建工程:
mvn archetype:generate -DarchetypeCatalog=local
以上就是创建自定义Archetype的简单流程。
比如对于策略模式,我们通常是定义一个接口,然后有不同的实现,这种是可以的,但是如果通用流程中要扩展的点较多的话,这些不同的实现也需要管理,可以把他们合并到一个单独的包中,再进一步,我们甚至可以将包单独提取出来,支持运行时加载包实现新增功能的支持
JDK对此功能的支持就是 SPI,但是它的限制较多,也不够灵活,比如dubbo就是自己定义了一套SPI的实现,这次我们来看另一个实现,pf4j 提供一套在基本框架中定义扩展点接口,然后通过不同的插件来实现扩展点的功能,来支持对新增开放对修改关闭
下面我们就来学习一下它的使用
使用
比如我们有一套通用的流程,假设是下单流程,不同的业务线等对于下单都有一些特殊点,但是它们的基本流程是相似的,这时候我们就可以先定义好通用的流程,不同的地方预留出扩展点接口,使用 pf4j 的流程如下
先定义好扩展点接口(需要定义单独的包,因为基本应用和各个扩展点的包都依赖它)
定义单独的插件包,其中实现扩展点接口的功能
在应用中编写基本流程和扩展点的发现使用功能
这次我们就参考 pf4j 提供的例子来看一下
1. 定义扩展点接口
pom.xml首先声明依赖
<dependency>
<groupId>org.pf4j</groupId>
<artifactId>pf4j</artifactId>
<version>3.6.0</version>
<!-- 一般应用中会依赖这个包,所以这里设置为provided即可 -->
<scope>provided</scope>
</dependency>
之后即可声明各个扩展点接口
/**
* 假设我们需要一个通知用户的功能
* 需要注意的是,我们一定要继承 ExtensionPoint 接口,表示这是一个扩展点
*/
public interface Notice extends ExtensionPoint {
boolean notice(List<Long> userIds);
}
本文例子基于Github地址:https://github.com/pf4j/pf4j
<dependency>
<groupId>org.pf4j</groupId>
<artifactId>pf4j</artifactId>
<version>3.6.0</version>
</dependency>
插件项目会涉及到3个工程:工程结构
plugin-api:定义可扩展接口
plugins:插件项目,可以包含多个插件,需要实现plugin-api中定义的接口
plugin-app:主程序,需要依赖plugin-api,加载并执行plugins
定义可扩展接口(plugin-api)
简单定义一个接口,需继承ExtensionPoint:
package plugin.api;
import org.pf4j.ExtensionPoint;
public interface Greeting extends ExtensionPoint {
String getGreeting();
}
实现插件(plugins)
插件需要实现plugin-api定义的接口,并且使用@Extension标记:
package plugins;
import org.pf4j.Extension;
import plugin.api.Greeting;
@Extension
public class WelcomeGreeting implements Greeting {
public String getGreeting() {
return "Welcome";
}
}
插件打包(plugins)
插件打包时,需要往MANIFEST.MF写入插件信息,此处使用maven插件(打包命令为package):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<archive>
<manifestEntries>
<Plugin-Id>welcome-plugin</Plugin-Id>
<Plugin-Version>0.0.1</Plugin-Version>
</manifestEntries>
</archive>
</configuration>
</plugin>
1 连接数(Connects)
最大使用连接数:show status like ‘Max_used_connections’
当前打开的连接数:show status like ‘Threads_connected’
2 缓存(bufferCache)
未从缓冲池读取的次数:show status like ‘Innodb_buffer_pool_reads’
从缓冲池读取的次数:show status like ‘Innodb_buffer_pool_read_requests’
缓冲池的总页数:show status like ‘Innodb_buffer_pool_pages_total’
缓冲池空闲的页数:show status like ‘Innodb_buffer_pool_pages_free’
缓存命中率计算:(1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests)*100%
缓存池使用率为:((Innodb_buffer_pool_pages_total-Innodb_buffer_pool_pages_free)/Innodb_buffer_pool_pages_total)*100%
3 锁(lock)
锁等待个数:show status like ‘Innodb_row_lock_waits’
平均每次锁等待时间:show status like ‘Innodb_row_lock_time_avg’
查看是否存在表锁:show open TABLES where in_use>0;有数据代表存在锁表,空为无表锁
4 SQL
查看 mysql 开关是否打开:show variables like ‘slow_query_log’,ON 为开启状态,如果为 OFF,set global slow_query_log=1 进行开启
查看 mysql 阈值:show variables like ‘long_query_time’,根据页面传递阈值参数,修改阈值 set global long_query_time=0.1
查看 mysql 慢 sql 目录:show variables like ‘slow_query_log_file’
格式化慢 sql 日志:mysqldumpslow -s at -t 10 /export/data/mysql/log/slow.log
注:此语句通过 jdbc 执行不了,属于命令行执行。
意思为:显示出耗时最长的 10 个 SQL 语句执行信息,10 可以修改为 TOP 个数。显示的信息为:执行次数、平均执行时间、SQL 语句
5 statement
insert 数量:show status like ‘Com_insert’
delete 数量:show status like ‘Com_delete’
update 数量:show status like ‘Com_update’
select 数量:show status like ‘Com_select’
6 吞吐(Database throughputs)
发送吞吐量:show status like ‘Bytes_sent’
接收吞吐量:show status like ‘Bytes_received’
总吞吐量:Bytes_sent+Bytes_received
7 数据库参数(serverconfig)
show variables8 慢 SQL
慢 SQL 指的是 MySQL 慢查询,具体指运行时间超过 long_query_time 值的 SQL。我们常听 MySQL 中有二进制日志 binlog、中继日志 relaylog、重做回滚日志 redolog、undolog 等。针对慢查询,还有一种慢查询日志 slowlog,用来记录在 MySQL 中响应时间超过阀值的语句。慢 SQL 对实际生产业务影响是致命的,所以测试人员在性能测试过程中,对数据库 SQL 语句执行情况实施监控,给开发提供准确的性能优化意见显得尤为重要。那怎么使用 Mysql 数据库提供的慢查询日志来监控 SQL 语句执行情况,找到消耗较高的 SQL 语句,以下详细说明一下慢查询日志的使用步骤:
确保打开慢 SQL 开关 slow_query_log
设置慢 SQL 域值 long_query_time
这个 long_query_time 是用来定义慢于多少秒的才算 “慢查询”,注意单位是秒,我通过执行 sql 指令 set long_query_time=1 来设置了 long_query_time 的值为 1, 也就是执行时间超过 1 秒的都算慢查询。
查看慢 SQL 日志路径
通过慢 sql 分析工具 mysqldumpslow 格式化分析慢 SQL 日志
mysqldumpslow 慢查询分析工具,是 mysql 安装后自带的,可以通过./mysqldumpslow —help 查看使用参数说明
取出使用最多的 10 条慢查询
./mysqldumpslow -s c -t 10 /export/data/mysql/log/slow.log取出查询时间最慢的 3 条慢查询
./mysqldumpslow -s t -t 3 /export/data/mysql/log/slow.log
假如: SELECT FROM sms_send WHERE service_id=10 GROUP BY content LIMIT 0, 1000;
mysqldumpslow 命令执行后显示:
Count: 2 Time=1.5s (3s) Lock=0.00s (0s) Rows=1000.0 (2000), vgos_dba[vgos_dba]@[10.130.229.196]SELECT FROM sms_send WHERE service_id=N GROUP BY content LIMIT N, Nmysqldumpslow 的分析结果详解:
Count:表示该类型的语句执行次数,上图中表示 select 语句执行了 2 次。
Time:表示该类型的语句执行的平均时间(总计时间)
Lock:锁时间 0s。
Rows:单次返回的结果数是 1000 条记录,2 次总共返回 2000 条记录。
不使用子查询
SELECT FROM t1 WHERE id (SELECT id FROM t2 WHERE name=’hechunyang’);
子查询在 MySQL5.5 版本里,内部执行计划器是这样执行的:先查外表再匹配内表,而不是先查内表 t2,当外表的数据很大时,查询速度会非常慢。
在 MariaDB10/MySQL5.6 版本里,采用 join 关联方式对其进行了优化,这条 SQL 会自动转换为 SELECT t1. FROM t1 JOIN t2 ON t1.id = t2.id;
但请注意的是:优化只针对 SELECT 有效,对 UPDATE/DELETE 子 查询无效, 生产环境尽量应避免使用子查询。避免函数索引
SELECT FROM t WHERE YEAR(d) >= 2016;
由于 MySQL 不像 Oracle 那样⽀持函数索引,即使 d 字段有索引,也会直接全表扫描。
应改为 > SELECT FROM t WHERE d >= ‘2016-01-01’;用 IN 来替换 OR 低效查询
慢 SELECT FROM t WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30;
高效查询 > SELECT FROM t WHERE LOC_IN IN (10,20,30);LIKE 双百分号无法使用到索引
SELECT FROM t WHERE name LIKE ‘%de%’;
使用 SELECT FROM t WHERE name LIKE ‘de%’;分组统计可以禁止排序
SELECT goods_id,count() FROM t GROUP BY goods_id;
默认情况下,MySQL 对所有 GROUP BY col1,col2… 的字段进⾏排序。如果查询包括 GROUP BY,想要避免排序结果的消耗,则可以指定 ORDER BY NULL 禁止排序。
使用 SELECT goods_id,count () FROM t GROUP BY goods_id ORDER BY NULL;禁止不必要的 ORDER BY 排序
SELECT count(1) FROM user u LEFT JOIN user_info i ON u.id = i.user_id WHERE 1 = 1 ORDER BY u.create_time DESC;
使用 SELECT count (1) FROM user u LEFT JOIN user_info i ON u.id = i.user_id;
9 总结
任何东西不应过重关注其外表,要注重内在的东西,往往绚丽的外表下会有对应的负担和损耗。
mysql 数据库的监控支持通过 SQL 方式从 performance_schema 库中访问对应的表数据,前提是初始化此库并开启监控数据写入。
对于监控而言,不在于手段的多样性,而需要明白监控的本质,以及需要的监控项内容,找到符合自身项目特色的监控方式。
在选择监控工具对 mysql 监控时,需要关注监控工具本身对于数据库服务器的消耗,不要影响到其自身的使用。
报错原因为配置中找不到一个指定自动注入类型的bean。
那么我们要从collecter层开始查找,点击service层,看service实现类是否加上@Service或者@Component,检查service实现类是否有implements service。如果这些都没有问题:
我们来看@SpringBootApplication,点过去。可以看到有个@ComponentScan,ComponentScan做的事情就是告诉Spring从哪里找到bean
那可以直接在@SpringBootApplication加上
还有一种问题,你的spring启动类不在同一个父包路径下,比如你的其它类在com.heckjj.blog,而你的启动类在heckjj下,也会报错扫不到其它的类,比如说service找不到。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<encoding>UTF-8</encoding>
<nonFilteredFileExtensions>
<nonFilteredFileExtension>xls</nonFilteredFileExtension>
<nonFilteredFileExtension>xlsx</nonFilteredFileExtension>
</nonFilteredFileExtensions>
</configuration>
</plugin>
问题产生的原因:
由于我远程的Oracle是 11g的,但是Navicat本身的Oracle oci.dll文件是10g的,数据库与链接库的版本不一致,所以会报错。
打开navicat的安装目录,查看有没有以下文件:
解决方案:
1、我们去Oracle官网下载对应的Instant Client Package -Version 11.2.0.4.0 - Basic的文件即可
下载地址:Instant Client for Microsoft Windows (x64) 64-bit
或者自行网上搜索下载
下载好之后,解压到navicat安装目录下
2、启动navicat客户端 找到【工具】->【选项】->【环境】
将OCI环境更改为11_2下的oci.dll即可,重启之后即可生效!